警告符号

Warning: ヘッダー (HTTP)

[30] Warning: ヘッダーは、 キャッシュその他による配送中のメッセージの処理に関する警告を表します。

仕様書

意味

[5] Warning: ヘッダー状態符号に反映されないかもしれないメッセージの状態や変形についての追加情報を伝えるものです >>3

[7] Warning: ヘッダーの警告の意味は、 警告符号によって表されます。警告にはキャッシュに関連するものもあれば、 そうでないものもあります >>3

[8] HTTP 応答メッセージでは状態符号によって誤りを表すこともできますが、 警告符号は真の失敗ではなく、状態符号とは独立した付加情報としての警告を表しています。

[6] Warning: ヘッダーはどのHTTPメッセージでも使うことができます。 ただし一部の警告符号キャッシュ専用で、応答メッセージにしか適用されません。 >>3

構文

[9] Warning: ヘッダーの値は、 1つ以上の警告値のリスト (#) です >>3

  1. 警告値
  2. *
    1. OWS
    2. ,
    3. OWS
    4. 警告値

[15] 警告値は、警告符号警告エージェント、警告テキスト、警告日時を SP で区切って並べたものです。ただし警告日時とその直前の SP は省略できます。 >>3

  1. 警告符号
  2. SP
  3. 警告エージェント
  4. SP
  5. 警告テキスト
  6. ?
    1. SP
    2. 警告日時

文脈

[40] このヘッダーは、複数指定できます >>3

[42] Warning: ヘッダー生成する送信者利用者エージェントの表示順 (>>41) を念頭に置いて Warning: ヘッダーの順序を決めることを推奨 (encourage) します。 新しい Warning: ヘッダー生成する場合は既存の Warning: ヘッダーの後に追加しなければなりません>>3

[43] 同時に複数の警告を生成するときの順序は表示順をもとに決めるべきであるものの、 既存の警告に割り込んではいけないということのようです。

警告符号

[17] 警告符号 (warn-code) は、 3桁のASCII数字です >>3

  1. ASCII数字
  2. ASCII数字
  3. ASCII数字
[33] RFC 2068 では2桁数字でしたが、 RFC 2616 で3桁に改められました。
[34] 同じく3桁数字である状態符号とは、まったく関係がありません。 同じ値が使われることがありますが、意味はまったく異なります。

[45] HTTP は100番台と200番台を使っています。

[46] SIP は300番台を使っており、意味により次のように割り当てられています。

  • [22] 300329 は、セッション記述中の見出し語に問題があったことを示します。
  • [23] 330 番台はセッション記述中で要求された基本的なネットワーク・サービスに問題があることを示します。
  • [24] 370 番台はセッション記述中で要求された quantitative QoS 引数に問題があることを示します。
  • [25] 390 番台はその他です。

[18]

10Response is stale[RFC 2068]
11Revalidation failed[RFC 2068]
12Disconnected operation[RFC 2068]
13Heuristic expiration[RFC 2068]
14Transformation applied[RFC 2068]
99Miscellaneous warning[RFC 2068]
110Response is stale[RFC 2616]
111Revalidation failed[RFC 2616]
112Disconnected operation[RFC 2616]
113Heuristic expiration[RFC 2616]
199Miscellaneous warning[RFC 2616]
214Transformation applied[RFC 2616]
299Miscellaneous persistent warning[RFC 2616]
300Incompatible network protocol[RFC 2543], [RFC 3261]
301Incompatible network address formats[RFC 2543], [RFC 3261]
302Incompatible transport protocol[RFC 2543], [RFC 3261]
303Incompatible bandwidth units[RFC 2543], [RFC 3261]
304Media type not available[RFC 2543], [RFC 3261]
305Incompatible media format[RFC 2543], [RFC 3261]
306Attribute not understood[RFC 2543], [RFC 3261]
307Session description parameter not understood[RFC 2543], [RFC 3261]
330Multicast not available[RFC 2543], [RFC 3261]
331Unicast not available[RFC 2543], [RFC 3261]
370Insufficient bandwidth[RFC 2543], [RFC 3261]
380
381
399Miscellaneous warning[RFC 2543], [RFC 3261]

[48] HTTP >>66, >>67SIP >>47 でそれぞれ IANA登録簿があります。

[68] HTTP の登録簿は RFC 7234 で新設されました。

[71] 警告符号の一覧は >>70JSON ファイルにも含まれています。

警告テキスト

[36] 警告テキスト (warn-text) は、引用文字列です >>3

  1. 引用文字列

[60] 警告テキストは、エラーを説明するもので、例えば記録のために用いるものです。 この値は単なるヒントで、警告符号の解釈には影響しません。 >>3

[65] 警告符号には、それぞれ推奨 (recommend) される英語の警告テキストが定義されています >>3。しかしそれしか指定できないわけではありませんし、英語である必要もないようです。

[61] RFC 2616 までは引用文字列内に符号化語を用いることができるとされていましたが、誰も実装していませんでした。 RFC 723x ではこの規定は削除されています。

[27] warn-textDQN な仕様だなぁ。 ここに encoded-word を使ってもいい ってことは、 quoted-string の中身が encoded-word, ということですよねぇ? (でないと構文に適合しないし、 encoded-word が複数個になった時に面倒だし。) でもそれは MIME の設計的には良いことではありません (もちろん HTTP は MIME ではありませんが...)
[62] RFC 2047 の符号化方式らしいですけど、 RFC 2231 の改訂 (言語指定) は適用されるのでしょうか。この仕様書は RFC 2616 ですから、 RFC 2231 の発行より後なのでして・・。

[28] SIP/2.0 では warn-textUTF-8 であり、 encoded-word が使えるとは書かれていません。使えないのでしょう。 warn-text の既定の言語は i-default です。

警告日時

[37] 警告日時 (warn-date) は、 HTTP-date" で括ったものです >>3

  1. "
  2. HTTPの日時形式
  3. "
[29] RFC 2068 では、 warn-date は定義されていませんでした。 warn-date は RFC 2616 で追加されました。
[57] RFC 2068 から分家した SIP/2.0 でも warn-date は定義されていません。

[58] 1xx では警告日時を含めるべき条件が規定されています。

1xx を参照。

[59] それ以外の場合について生成して良いとも悪いとも言及されていません。

処理

[41] Warning: ヘッダーを受信した利用者エージェントは、 そのできるだけ多くを出現順で利用者に通知するべきです >>3

[44] 実際に表示する利用者エージェントがあるのかは不明です。

[51] 具体的にどう表示するべきなのかは特に規定がないようです。

[52] 未知の警告符号の場合にどうするかは特に規定がありません。 また RFC 2068 から RFC 2616 への改訂時に構文が非互換変更されましたが、 それも含めて非妥当Warning: ヘッダーを受信した時にどう処理するべきかは特に言及がありません。

[63] 受信者Warning: ヘッダーを利用、評価、表示する場合は、 警告日時が Date: ヘッダーと異なっている場合、 蓄積転送、利用の前に当該警告値を削除しなければなりません >>3。 すべての警告値を削除した場合には、 Warning: ヘッダー全体を削除しなければなりません >>3

[64] これによってキャッシュ検証後に誤って残されている警告値を除去します >>3
[69] Date: がない場合や警告日時がない場合は、 削除しなくて良いと思われます。

歴史

[26] RFC 2068HTTP に導入された際には応答で用いるヘッダーとされていました。

[53] RFC 2616 ではこれが要求でも使えるように拡張されました。

[54] RFC 2068 から派生した SIP では応答のみで使えることになっています。

[55] なお RTSP には Warning: ヘッダーはありません。
[4] RFC 2068 (HTTP/1.1) 14.45; RFC 2616 (HTTP/1.1) 14.46 Warning

The Warning response-header general-header field is used to carry additional information about the status or transformation of a response which may might not be reflected by the response status code in 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 = 2DIGIT
  • warn-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 may MAY carry more than one Warning header.

応答は1つ以上の Warning 頭を運んで構いません

The warn-text should SHOULD be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. This decision may MAY 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 1522 2047 [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 headers should SHOULD be added after any existing Warning headers. A cache MUST NOT delete any Warning header that it received with a response message. 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 display ought 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 to display inform the user of all of the warnings, the user agent should SHOULD 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-codewarn-agent が同じでありながらも他の文字集合で書かれたものよりも優先させる。

Systems that generate multiple Warning headers should SHOULD 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.
110 応答は腐っています
返される応答が腐敗しているときには必ず含めなければなりませんキャッシュはこの警告を任意の応答に追加して構いませんが、応答が新鮮と分かるまでは決して削除してはなりません。
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.
111 再検証失敗
キャッシュが、に到達する能力がなかったために応答の妥当性を再検証する試行に失敗したため、腐った応答を返すときに含めなければなりませんキャッシュはこの警告を任意の応答に追加して構いませんが、応答を成功裏に再検証するまでは決して削除してはなりません。
112 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from the rest of the network for a period of time.
112 未接続操作
キャッシュがある時間中ネットワークの他の部分と意図的に接続されていないときに含めるべきです
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.
113 発見的満期
キャッシュが発見的に24時間よりも大きな新鮮寿命を選び、 応答のが24時間よりも大きいときに含めなければなりません
199 Miscellaneous warning
The warning text may MAY 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.
119 その他の警告
警告文は、人間利用者に示される、または記録される、任意の情報を含めて構いません。 この警告を受信したシステムは、利用者に警告を示す他に、自動の動作を行ってはなりません
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.
214 変形適用済み
中間キャッシュまたはが、応答の 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.
299 その他の持続警告
警告文は、人間利用者に示される、または記録される、任意の情報を含めて構いません。 この警告を受信したシステムは、利用者に警告を示す他に、自動の動作を行ってはなりません

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 頭も同様に削除しなければなりません

>>3
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
[19] Zalando RESTful API と イベントスキーマのガイドライン () <https://restful-api-guidelines-ja.netlify.com/>

廃止予定フェーズの間、 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停止の同意を得たとはいえません。