[30] Warning:
ヘッダーは、
キャッシュその他による配送中のメッセージの処理に関する警告を表します。
[5] Warning:
ヘッダーは状態符号に反映されないかもしれないメッセージの状態や変形についての追加情報を伝えるものです
>>3。
[7] Warning:
ヘッダーの警告の意味は、
警告符号によって表されます。警告にはキャッシュに関連するものもあれば、
そうでないものもあります >>3。
[8] HTTP 応答メッセージでは状態符号によって誤りを表すこともできますが、 警告符号は真の失敗ではなく、状態符号とは独立した付加情報としての警告を表しています。
[6] Warning:
ヘッダーはどのHTTPメッセージでも使うことができます。
ただし一部の警告符号はキャッシュ専用で、応答メッセージにしか適用されません。
>>3
[9] Warning:
ヘッダーの値は、
1つ以上の警告値のリスト (#
) です >>3。
[15] 警告値は、警告符号、警告エージェント、警告テキスト、警告日時を
SP
で区切って並べたものです。ただし警告日時とその直前の
SP
は省略できます。 >>3
[42] Warning:
ヘッダーを生成する送信者は利用者エージェントの表示順 (>>41)
を念頭に置いて Warning:
ヘッダーの順序を決めることを推奨します。
新しい Warning:
ヘッダーを生成する場合は既存の
Warning:
ヘッダーの後に追加しなければなりません。
>>3
[17] 警告符号 (warn-code
) は、
3桁のASCII数字です >>3。
[45] HTTP は100番台と200番台を使っています。
[46] SIP は300番台を使っており、意味により次のように割り当てられています。
10 | Response is stale | [RFC 2068] |
11 | Revalidation failed | [RFC 2068] |
12 | Disconnected operation | [RFC 2068] |
13 | Heuristic expiration | [RFC 2068] |
14 | Transformation applied | [RFC 2068] |
99 | Miscellaneous warning | [RFC 2068] |
110 | Response is stale | [RFC 2616] |
111 | Revalidation failed | [RFC 2616] |
112 | Disconnected operation | [RFC 2616] |
113 | Heuristic expiration | [RFC 2616] |
199 | Miscellaneous warning | [RFC 2616] |
214 | Transformation applied | [RFC 2616] |
299 | Miscellaneous persistent warning | [RFC 2616] |
300 | Incompatible network protocol | [RFC 2543], [RFC 3261] |
301 | Incompatible network address formats | [RFC 2543], [RFC 3261] |
302 | Incompatible transport protocol | [RFC 2543], [RFC 3261] |
303 | Incompatible bandwidth units | [RFC 2543], [RFC 3261] |
304 | Media type not available | [RFC 2543], [RFC 3261] |
305 | Incompatible media format | [RFC 2543], [RFC 3261] |
306 | Attribute not understood | [RFC 2543], [RFC 3261] |
307 | Session description parameter not understood | [RFC 2543], [RFC 3261] |
330 | Multicast not available | [RFC 2543], [RFC 3261] |
331 | Unicast not available | [RFC 2543], [RFC 3261] |
370 | Insufficient bandwidth | [RFC 2543], [RFC 3261] |
380 | ||
381 | ||
399 | Miscellaneous warning | [RFC 2543], [RFC 3261] |
[36] 警告テキスト (warn-text
) は、引用文字列です >>3。
[60] 警告テキストは、エラーを説明するもので、例えば記録のために用いるものです。 この値は単なるヒントで、警告符号の解釈には影響しません。 >>3
[65] 警告符号には、それぞれ推奨される英語の警告テキストが定義されています >>3。しかしそれしか指定できないわけではありませんし、英語である必要もないようです。
[61] RFC 2616 までは引用文字列内に符号化語を用いることができるとされていましたが、誰も実装していませんでした。 RFC 723x ではこの規定は削除されています。
warn-text
は DQN な仕様だなぁ。
ここに encoded-word
を使ってもいい
ってことは、 quoted-string
の中身が
encoded-word
,
ということですよねぇ? (でないと構文に適合しないし、
encoded-word
が複数個になった時に面倒だし。)
でもそれは MIME の設計的には良いことではありません
(もちろん HTTP は MIME ではありませんが...)。RFC 2047 の符号化方式らしいですけど、 RFC 2231 の改訂 (言語指定) は適用されるのでしょうか。この仕様書は RFC 2616 ですから、 RFC 2231 の発行より後なのでして・・。
[28] SIP/2.0 では warn-text
は UTF-8 であり、 encoded-word
が使えるとは書かれていません。使えないのでしょう。
warn-text
の既定の言語は
i-default
です。
[37] 警告日時 (warn-date
) は、 HTTP-date
を "
で括ったものです >>3。
[58] 1xx
では警告日時を含めるべき条件が規定されています。
1xx
を参照。[41] Warning:
ヘッダーを受信した利用者エージェントは、
そのできるだけ多くを出現順で利用者に通知するべきです >>3。
[51] 具体的にどう表示するべきなのかは特に規定がないようです。
[52] 未知の警告符号の場合にどうするかは特に規定がありません。
また RFC 2068 から RFC 2616 への改訂時に構文が非互換変更されましたが、
それも含めて非妥当な Warning:
ヘッダーを受信した時にどう処理するべきかは特に言及がありません。
[63] 受信者が Warning:
ヘッダーを利用、評価、表示する場合は、
警告日時が Date:
ヘッダーと異なっている場合、
蓄積、転送、利用の前に当該警告値を削除しなければなりません >>3。
すべての警告値を削除した場合には、 Warning:
ヘッダー全体を削除しなければなりません >>3。
[26] RFC 2068 で HTTP に導入された際には応答で用いるヘッダーとされていました。
[53] RFC 2616 ではこれが要求でも使えるように拡張されました。
[54] RFC 2068 から派生した SIP では応答のみで使えることになっています。
The Warning
response-headergeneral-header field is used to carry additional information about the status or transformation of a response whichmaymight not be reflectedby the response status codein the message. This information is typically, though not exclusively,used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message.
Warning
一般頭欄は、応答状態符号にメッセージ中に反映されていないかもしれない応答の状態や変形についての追加情報を伝達するために使います。
この情報は、典型的にはキャッシュ操作の意味的透過性の欠如の可能性があることやメッセージの実体本体に変形が行われたことを警告するために使います。
Warning headers are sent with responses using:
Warning
頭は、応答で次を使って送信します。
- Warning = "Warning" ":" 1#warning-value
- warning-value = warn-code SP warn-agent SP warn-text [SP warn-date]
warn-code = 2DIGITwarn-code = 3DIGIT- warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding ; the Warning header, for use in debugging- warn-text = quoted-string
- warn-date = <"> HTTP-date <">
A response
mayMAY carry more than one Warning header.
応答は1つ以上の Warning 頭を運んで構いません。
The warn-text
shouldSHOULD be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. This decisionmayMAY be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1.
warn-text は応答を受け取る人間利用者が理解可能と最も思われる 自然言語と文字集合を使うべきです。この決定はいかなる利用可能な知識、 例えばキャッシュや利用者の位置, 要求の Accept-Language 欄, 要求の Content-Language 欄, などなどを基にして構いません。 既定言語は英語で既定文字集合は ISO-8859-1 です。
If a character set other than ISO-8859-1 is used, it MUST be encoded in the warn-text using the method described in RFC
15222047 [14].
ISO-8859-1 以外の文字集合が使われる場合は、 RFC 2047 で説明されている方法を使って warn-text を符号化しなければなりません。
Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can only be applied to response messages.
Any server or cache may add Warning headers to a response.New Warning headersshouldSHOULD be added after any existing Warning headers. A cache MUST NOT delete any Warning header that it received with aresponsemessage. However, if a cache successfully validates a cache entry, it SHOULD remove any Warning headers previously attached to that entry except as specified for specific Warning codes. It MUST then add any Warning headers received in the validating response. In other words, Warning headers are those that would be attached to the most recent relevant response.
Warning
頭は、一般に任意のメッセージに適用できます。
しかし、幾つかの特定の warn-code
はキャッシュに特有のものであり、
応答メッセージにのみ適用できます。
新しい Warning
頭は既存の Warning
頭群の後に追加するべきです、キャッシュは、
その受信したメッセージ内の Warning
頭を削除してはなりません。
しかし、キャッシュがキャッシュ項目を成功裏に妥当性検証したのなら、
特定の Warning
符号について指定されたものを除いて、
その項目に以前に付された Warning
頭群んは削除するべきです。
キャッシュは、その際に検証応答で受信した Warning
頭欄をすべて追加しなければなりません。言い換えれば、
Warning
頭は最近の関係する応答に付されたものとします。
When multiple Warning headers are attached to a response, the user agent
SHOULD displayought to inform the user of as many of them as possible, in the order that they appear in the response. If it is not possible todisplayinform the user of all of the warnings, the user agentshouldSHOULD follow these heuristics:
複数の Warning
頭群が応答に付されている時は、
利用者エージェントはそのうちのできるだけ多くを、
応答に出現した順で利用者に示すべきです。
警告のすべてを利用者に示すことが不可能である時は、
利用者エージェントは次の発見的方法に従うべきです。
o- Warnings that appear early in the response take priority over those appearing later in the response.o- Warnings in the user's preferred character set take priority over warnings in other character sets but with identical warn-codes and warn-agents.
Warning
は、
応答の後のほうで現れたものよりも優先させるWarning
は、 warn-code
と warn-agent
が同じでありながらも他の文字集合で書かれたものよりも優先させる。Systems that generate multiple Warning headers
shouldSHOULD order them with this user agent behavior in mind.
複数の Warning
頭を生成するシステムは、この利用者エージェントの振る舞いを念頭に置いて順序を決めるべきです。
Requirements for the behavior of caches with respect to Warnings are stated in section 13.1.2.
Warning
に関するキャッシュの振る舞いの要件は13.1.2節で述べています。
This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its meaning.
これは、現在定義されている warn-code
と、それぞれについての推奨する英語での warn-text
とその意味の説明の一覧です。
- 110 Response is stale
- MUST be included whenever the returned response is stale.
A cache may add this warning to any response, but may never remove it until the response is known to be fresh.
- 111 Revalidation failed
- MUST be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability to reach the server.
A cache may add this warning to any response, but may never remove it until the response is successfully revalidated.
- 112 Disconnected operation
- SHOULD be included if the cache is intentionally disconnected from the rest of the network for a period of time.
- 113 Heuristic expiration
- MUST be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
- 199 Miscellaneous warning
- The warning text
mayMAY include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.
- 214 Transformation applied
- MUST be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the response, unless this Warning code already appears in the response.
MUST NOT be deleted from a response even after revalidation.
content-coding
(Content-Encoding
頭で指定されます。) または media-type
(Content-Type
で指定されます。) または応答の entity-body
を変更する何らかの変形を適用した場合に、
この Warning
符号が既に応答に現れている場合を除き、
追加しなければなりません。
- 299 Miscellaneous persistent warning
- The warning text MAY include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action.
If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender MUST include in each warning-value a warn-date that matches the date in the response.
実装が一つ以上の Warning
頭群を含んだ版が HTTP/1.0 以下のメッセージを送信するときには、
送信者は各 warning-value
に応答の日付と一致する
warn-date
を含めなければなりません。
If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date value in the response, then that warning-value MUST be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning header fields.) If all of the warning-values are deleted for this reason, the Warning header MUST be deleted as well.
実装が warn-date
を含む warning-value
を含み、その warn-date
が応答の Date
値と異なるメッセージを受信したら、その warning-value
は、そのメッセージを蓄積、転送、または使用する前にメッセージから削除しなければなりません。
(これは、 Warning
頭欄を単純にキャッシュすることによる悪影響を防ぎます。)
すべての warning-value
がこの理由により削除される場合は、
Warning
頭も同様に削除しなければなりません。
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
廃止予定フェーズの間、 Warning ヘッダを付けましょう。 (RFC 7234 - Warning header をみてください)。 Warning が付いていたら、 warn-code は 299 を指定し、 warn-text は "The path/operation/parameter/… {name} is deprecated and will be removed by {date}. Please see {link} for details." の形式にしましょう。 link先は、なぜAPIがもはやサポートされないかと、クライアントがすべきことを記述した ドキュメントにします。 `Warning`ヘッダを付加しても、クライアントに対しAPI停止の同意を得たとはいえません。
[20] Warning: header & stale-while-revalidate · Issue #913 · whatwg/fetch () https://github.com/whatwg/fetch/issues/913
[31] draft-ietf-http-warning-00 - Problem with HTTP/1.1 Warning header, and proposed fix () https://tools.ietf.org/html/draft-ietf-http-warning-00
[32] Warning · Issue #139 · httpwg/http-core () https://github.com/httpwg/http-core/issues/139