HTTP//頭欄

HTTP//頭欄

[1] HTTPメッセージは、頭部本体の2部で構成されています。 頭部には、本体に関するメタ情報HTTP通信に関する制御情報などを頭欄 (かしららん) (header field) の集合体として記述します。 個々の頭欄は、欄名欄本体の組で構成されます。

欄名によって識別される頭欄の種類は、 HTTP本体規格で規定されている他、 各種周辺規格で追加のものが定義されています。

[2] 頭欄の分類: 頭欄は、使われる場所と意味によって4種類に分けられます。

一般頭欄
HTTP通信一般に関わる頭欄で、多くは要求でも応答でも使用されます。
要求頭欄
HTTP要求に関する頭欄です。
応答頭欄
HTTP応答に関する頭欄です。
実体頭欄
HTTP実体 (or 実現値) に関する頭欄です。 要求でも応答でも使われます。

[3] 頭欄の種類: 頭欄は、IETFRFCで規定されているもの、 他の標準化団体が規定したもの、 規定なしで勝手に使われているものなど色々あります。 長らくこの状況で放置されてきましたが、RFC 3864 (2004年、BCP 90) によってIANA登録手続きが成立し、RFC 4229 (2005年) でこれまでに標準化されたものが登録されました。

- IANA 登録簿: IANA | Message Header Messages <http://www.iana.org/assignments/message-headers/message-header-index.html>

頭欄一覧

[4]頭欄に移動

仕様書から

RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 4.2 Message Headers

HTTP header fields, which include General-Header (Section 4.3) general-header (section 4.5), Request-Header (Section 5.2) request-header (section 5.3), Response-Header (Section 6.2) response-header (section 6.2), and Entity-Header (Section 7.1) entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [7] [9] . Each header field consists of a name followed immediately by a colon (":"), a single space (SP) character, and the field value. Field names are case-insensitive. The field value may MAY be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT, though this is not recommended. Applications SHOULD ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.

HTTP 頭欄は、一般頭欄, 要求頭欄, 応答頭欄, 実体頭欄を含みますが、 RFC822 の3.1節にある同じ一般書式に従います。 各頭欄は名前、それにすぐに続くコロン (:)、1つの間隔 (SP) 文字、欄値から成ります。 欄名は大文字・小文字を区別しません。欄値の前には任意の量の LWS があって構いません。しかし SP 1つが好ましいです。 頭欄は、それぞれの余分な行に最低1つの SP または HT を入れることで複数行に展開できます。ただしこれは推奨しません。 応用は、 HTTP 構造体を生成する時に、 (それが知られているかまたは示されている時には)「共通形」に従うべきです。そうしないと、共通形以外のものを受け入れてくれない実装が存在するかもしれません。

  • HTTP-header = field-name ":" [ field-value ] CRLF
  • message-header = field-name ":" [ field-value ]]
  • field-name = token
  • field-value = *( field-content | LWS )
  • field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, tspecials {2616} separators, and quoted-string OCTET 並びが field-value を形成し、 *TEXT または token, tspecials CODE(ABNF)separators, quoted-string の組合せのいずれかにより構成する>

{2616} The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS MAY be removed without changing the semantics of the field value. Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.

field-content は最初や最後の LWS、つまり field-value の最初の非空白文字の前や最後の非空白文字の後の線形空白を含みません。 この最初や最後の LWS は欄値の意味を変えずに削除して構いませんfield-content の間に現れる任意の LWS は欄値を解釈したりメッセージを下流に転送したりする前に1つの SP に置換しても構いません

The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send General-Header general-header fields first, followed by Request-Header request-header or Response-Header response-header fields, and ending with prior to the Entity-Header entity-header fields.

どの順序で名前の異なる頭欄を受信したかは重要ではありません。 しかし、一般頭欄を最初に送り、続けて要求頭欄または応答頭欄を実体頭欄の前に送るのが 「良い習慣」です。

Multiple HTTP-header message-header fields with the same field-name {1945,2068} may {2616} MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It must MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

同じ field-name の複数の message-header は、その頭欄の field-value 全体が読点分離並び (つまり #(values)) として定義されているときに、 この場合に限って出現して構いません。 各後続 field-value を最初のものに、それぞれ読点で分離して後置することによって、 メッセージの意味を変えずに複数の頭欄を一つの field-name: field-value 組に結合することが可能でなければなりません

注: 注記なき追加・削除は 1945→2068 の差分。 追加部分の中の追加・削除は 2068→2616 の差分。

RFC の部分のライセンス

RFCのライセンス

メモ

[5] HTTP interoperability - Anne’s Weblog ( 版) <http://annevankesteren.nl/2007/10/http-interoperability> (名無しさん)