143.txt

[17] [[HTTP]] における[DFN[[RUBYB[[[ヘッダー]]]@en[header]]]]は、
当該[[メッセージ]]の解釈や処理の方法に関する情報を入れる欄です。
[[ヘッダー]]は[[名前]] ([[欄名]]) と値 ([[欄値]]) の組です。
[[メッセージ]]には任意の個数[[ヘッダー]]を含められます。

[18] [[HTTP]] 仕様書では[[ヘッダー]]は[DFN[[RUBYB[[[頭欄]]]@en[header field]]]]
([DFN[[[ヘッダーフィールド]]]]) と呼ばれます。
一般的には、また [[HTTP]] 以外の多くの [[Web]] 関連仕様では、単に[[ヘッダー]]と呼ばれています。

;; [19] 「header field」という用語は [[HTTP]] が影響を受けた [[RFC 822]]
などの[[電子メール]]仕様の用語に由来しますが、[[電子メール]]においても一般的には[[ヘッダー]]と呼ばれています。

* 仕様書

[REFS[
- [12] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.2>'''
- [434] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#page-50>
- [39] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-8.3>
- [62] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) <https://tools.ietf.org/html/rfc6968#page-7>
- [66] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) <https://tools.ietf.org/html/rfc6968#section-4.1>
- [73] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-4.3>
- [82] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-5.5>
- [84] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-6.5.2>
- [90] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-7>
- [92] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-8.1.2>
]REFS]

* テキスト形式メッセージ (HTTP/1.x) におけるヘッダー

** 構文

[15] [[ヘッダー]]は、[[欄名]]、 [CODE(char)[[[:]]]]、[[欄値]]で構成されます。
[[欄値]]の前後には[[空白]] ([CODE(ABNF)[[[OWS]]]]) を入れることができます。 [SRC[>>12]]
[[ヘッダー]]の直後には、必ず [[CRLF]] が必要です。

[16] [[欄名]]は、対応する[[欄値]]に対する[[名札]]となるもの [SRC[>>12]]
であり、[[欄値]]の構文と意味は[[欄名]]により決まります。

;; [433] 詳しくは[[欄名]]と[[欄値]]を参照してください。

[FIG(railroad)[
= [[字句]]
= [CODE[[[:]]]]
= [[OWS]]
= [[欄値]]
= [[OWS]]
]FIG]

[432] [[HTTP]] においては[[ヘッダー]]の値が[[空文字列]]であることと、
[[ヘッダー]]が指定されていないことは同義ではありません。また[[空文字列]]は非推奨でも何でもなく、
定義上[[空文字列]]であることが要求されている場面もあります。

[54] また、[[ヘッダー]]の値が [CODE[0]] という文字列となることもあります。

[55] [[空文字列]]や [CODE[0]] を[[偽]]として扱う[[プログラミング言語]]で処理する際には注意が必要です。

** 構文解析

[35] [[HTTPメッセージ]]全体としての[[構文解析]]では、
[[ヘッダー]]の名前と値の構造までは[[構文解析]]しますが、
[[欄値]]は解釈が必要になるまで[[構文解析]]しないのが普通です。

;; [34] [[HTTPメッセージ]]の[[構文解析]]の項も参照してください。

[36] [[欄名]]と [CODE(char)[[[:]]]] の間には[[空白]]認められていません。
[[鯖]]は、[[空白]]がある場合 [CODE(HTTP)[[[400]]]]
[[応答]]を返して拒絶しなければ[['''なりません''']]。
[[串]]は、[[下流]]に[[転送]]する前に[[空白]]を削除しなければ[['''なりません''']]。
[SRC[>>12]]

;; [44] 歴史的に[[空白]]の扱いが異なる実装があったため、[[セキュリティー]]上の問題を引き起こしたことがありました
[SRC[>>43]]。

[37] [[欄値]]の前後の [[OWS]] は、[[欄値]]の一部ではなく、
[[構文解析]]の際に削除します [SRC[>>12]]。

[38] [[欄値]]には[[行折り畳み]]が含まれていることがあります。
その処理については、[[欄値]]、[[行折り畳み]]の項を参照してください。

[401] [[鯖]]は、処理したい長さより長い[[ヘッダー]]のある[[要求]]を受信した時は、
適切な [CODE(HTTP)[[[4xx]]]] [[状態符号]]で応答しなければ[['''なりません''']] [SRC[>>12]]。

;; [404] [CODE(HTTP)[[[431]]]] が適当そうですが、限定されていないのには何か意味があるのでしょうか?
([[HTTP]] 本体である [[RFC 723x]] に含まれていないという形式的な理由かもしれませんが、
仕様書はもっと実装者に有用な情報を提供してほしいものです...)

[402] [[クライアント]]は、処理したい長さより長い[[ヘッダー]]のある[[応答]]を受信した時は、
それによって[[メッセージ]]の[[フレーム付け]]や[[応答]]の意味が変わってしまわない限り、
当該[[ヘッダー]]を除去したり途中で切ったりしても構いません。 [SRC[>>12]]

;; [403] 意味が変わってしまう場合にどうするべきかは明記されていません。

[26] [[鯖]]は、[[要求]]の[[ヘッダー]]全体を[[受信]]するまで[[対象資源]]に[[要求]]を適用しては[['''なりません''']]
[SRC[>>12]]。

* バイナリー形式メッセージ (HTTP/2) におけるヘッダー

[74] [DFN[[RUBYB[ヘッダーリスト]@en[header list]]]]は、0個以上の [[header field]]
で構成されます [SRC[>>3]]。

[99] [[HTTP/1.1]] と共通の通常の [[HTTPヘッダー]]の他に、
[[HTTP/1.1]] の[[開始行]]に相当する[[疑似ヘッダー]]があります。
[[疑似ヘッダー]]は、通常の[[ヘッダー]]より前になければなりません [SRC[>>92]]。
また[[疑似ヘッダー]]は[[trailer]]では使えません [SRC[>>92]]。

;; [[疑似ヘッダー]]を参照。

[75] [[ヘッダーリスト]]は、 [[HTTPヘッダー圧縮]]により[DFN[[RUBYB[[[ヘッダーブロック]]]@en[header block]]]]として[[直列化]]されます [SRC[>>3]]。

[76] [[直列化]]された[[ヘッダーブロック]]は、1つ[[以上]]の[DFN[[RUBYB[[[ヘッダーブロック素片]]]@en[header block fragment]]]]に分割されて
[CODE[[[HEADERS]]]], [CODE[[[PUSH_PROMISE]]]], [CODE[[[CONTINUATION]]]]
の[[フレーム]]の [[payload]] で転送されます [SRC[>>3]]。

[77] [[ヘッダー]]を表す[[フレーム]]群は、 [CODE[[[HEADERS]]]] または
[CODE[[[PUSH_PROMISE]]]] で始まり、0個[[以上]]の [CODE[[[CONTINUATION]]]]
が続きます。最後の[[フレーム]]は [CODE[[[END_HEADERS]]]] [[フラグ]]が設定され、
それ以外の[[フレーム]]は設定されません。 [SRC[>>3]]

[80] [[ヘッダーブロック]]は連続した[[フレーム]]として転送しなければ[['''なりません''']]。
他の[[フレーム]]を挟んではなりません。 [SRC[>>3]]

[83] 未知の[[フレーム型]]の[[フレーム]]も挟めません [SRC[>>82]]。
[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]] としなければ[['''なりません''']] [SRC[>>82]]。

[FIG(railroad)[
= |
== [CODE[[[HEADERS]]]] ([CODE[[[END_HEADERS]]]])
== [CODE[[[PUSH_PROMISE]]]] ([CODE[[[END_HEADERS]]]])
== =
=== |
==== [CODE[[[HEADERS]]]] (¬[CODE[[[END_HEADERS]]]])
==== [CODE[[[PUSH_PROMISE]]]] (¬[CODE[[[END_HEADERS]]]])
=== *
==== [CODE[[[CONTINUATION]]]] (¬[CODE[[[END_HEADERS]]]])
=== [CODE[[[CONTINUATION]]]] ([CODE[[[END_HEADERS]]]])
]FIG]

[78] [[ヘッダー圧縮]]は状態を持ちます。[[接続]]毎に、
[[接続]]全体の[[圧縮文脈]]と[[展開文脈]]を1つずつ持ちます。 [SRC[>>3]]

[79] [[ヘッダーブロック]]の[[復号エラー]]は、[[接続エラー]]
[DFN[[CODE[[[COMPRESSION_ERROR]]]]]] としなければ[['''なりません''']] [SRC[>>3]]。

[81] [[受信者]]は、[[フレーム]]群が捨てられる場合であっても、
その[[フレーム]]群から[[ヘッダーブロック]]を結合し展開する必要があります。
[[受信者]]が持つ[[圧縮文脈]]を変更する可能性があります。 [SRC[>>3]]
[[展開]]しない場合は、[[接続エラー]]
[CODE[[[COMPRESSION_ERROR]]]] としなければ[['''なりません''']] [SRC[>>3]]。

[91] [[誤り符号]] [DFN[[CODE[[[COMPRESSION_ERROR]]]]]] ([CODE[[[0x9]]]])
は、[[接続]]の[[ヘッダー圧縮文脈]]を維持できないことを示します [SRC[>>90]]。

[85] [[設定]] [DFN[[CODE[[[SETTINGS_HEADER_TABLE_SIZE]]]]]] ([CODE[[[0x1]]]])
は、[[header block]] の[[復号]]に使う[[ヘッダー圧縮表]]の最大長を[[バイト]]単位で通知するものです。
[[符号化器]]は、[[header block]] 内の[[ヘッダー圧縮形式]]に依存した方法により、
この値[[以下]]の大きさを選ぶことができます。 [SRC[>>84]]

[87] 初期値は、 4096 [[バイト]]です。 [SRC[>>84]]

[86] [[設定]] [DFN[[CODE[[[SETTINGS_MAX_HEADER_LIST_SIZE]]]]]] ([CODE[[[0x6]]]]) は、
[[送信者]]が受け付ける準備のできている [[header list]] の最大長を知らせる[[ヒント]]です。
この値は、圧縮前の状態で、[[header field]] ごとに名前と値の長さとオーバーヘッドとして 32
を足した合計値を[[バイト]]単位にしたものです。 [SRC[>>84]]

[89] 各[[要求]]で、この値よりも小さな制限を課しても構いません [SRC[>>84]]。

[88] 初期値は、無制限です [SRC[>>84]]。

[95] [[ヘッダー名]]は[[小文字]]に変換してから記述しなければ[['''なりません''']] [SRC[>>92]]。

[96] [[大文字]]の[[ヘッダー名]]を含む[[メッセージ]]は、
[RUBYB[不正]@en[malformed]]です [SRC[>>92]]。

* 文脈

[13] [[HTTP/1.0]] や [[HTTP/1.1]] の [[HTTPメッセージ]]では、
[[ヘッダー]]は[[開始行]]と[[メッセージ本体]]の直前の空行との間に0個以上指定できます。

[94] [[HTTP/2]] の[[HTTPメッセージ]]では、
[[ヘッダー]]は [[header block]] の一部として記述できます。

[14] [[HTTP/0.9]] [[メッセージ]]には[[ヘッダー]]は指定できません。

[446] [[ヘッダー]]は [[HTTP/1.1]] や [[HTTP/2]] の[[トレーラー部]]にも0個以上指定できます。

[447] [[ヘッダー]]の種類 ([[ヘッダー名]]) や[[要求メッセージ]]、[[状態符号]]その他の文脈により、
それぞれ更に細かい制約があります。 (詳細は各[[ヘッダー]]の文脈の項を参照してください。)

;; [42] [[RFC 7231]] は[[ヘッダー]]の仕様書に対し、使っても良い文脈を明記することを検討するよう求めています [SRC[>>39]]。
しかし当の [[RFC 723x]] が、使って良い文脈を完全には明記していません。
使ってはいけない状況や使わなければならない文脈は明記されていることが多いですが、
その他の多くは曖昧にされています。

* ヘッダーの種類

[20] [[ヘッダー]]の種類は[[ヘッダー名]]により識別されます。
[[ヘッダー]]は、 [[HTTP]] 本体仕様で定義されている他、
追加の[[ヘッダー]]が随時追加されています。

[7] [[HTTPヘッダー]]には、 [[RFC]] で規定されているもの、
実装依存のものなど沢山の種類があります。詳しくは[[HTTPヘッダーの一覧]]を参照してください。

[21] [[ヘッダー名]]については、[[電子メール]]等と共通の [[IANA登録簿]]があります 
[SRC[>>438, >>39]]。定義された[[ヘッダー]]は、 [[IANA]] 
に登録する[RUBYB[べき]@en[ought to]]です [SRC[>>12]]。

;; [47] しかし実際には大多数の[[ヘッダー]]は登録されていません。
また [[HTTP]] 仕様上も登録されていない[[ヘッダー]]の利用は禁止されていないようです。

;; [93] 登録簿は共通ですが、定義や登録自体は別々です。
また[[電子メール]]よりも [[HTTP]] に近い [[RTSP]] や [[SIP]]
のような [[HTTP]] 派生プロトコルは、独自の [[IANA登録簿]]を使っています。

[22] [[串]]は、原則として認識できない[[ヘッダー]]を[[転送]]しなければ[['''なりません''']]
[SRC[>>12]]。 ([CODE(HTTP)@en[[[Connection:]]]] [[ヘッダー]]による指定や[[串]]の個別の設定など、
他の規定により[[転送]]しなくて良い場合もあります。)

;; >>435 も参照。

[23] [[串]]以外の[[受信者]]は、認識できない[[ヘッダー]]を無視する[['''べきです''']]
[SRC[>>12]]。

;; [51] ここでいう「無視」は、それによって特別な処理をしないことを指しています。
例えば[[Webブラウザー]]は、 [[XHR]] によって得られた[[応答]]に
([[Webブラウザー]]が) 知らない[[ヘッダー]]が含まれていたら、
それを [[XHR]] の [[API]] によって[[スクリプト]]に提供することが求められます
(「無視」して削除してはいけません)。

[REFS[
- [438] [CITE[Message Headers]] ([TIME[2014-06-13 18:50:11 +09:00]] 版) <http://www.iana.org/assignments/message-headers/>
- [437] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-8.1>
]REFS]

* ヘッダーの順序

[24] 異なる[[欄名]]の[[ヘッダー]]同士の順序は、意味を持ちません [SRC[>>12]]。

[27] 同名の[[ヘッダー]]の順序には意味があります [SRC[>>12]]。
[[串]]は[[転送]]の際にその順序を入れ替えては[['''なりません''']] [SRC[>>12]]。

[25] 制御データを含む [CODE(HTTP)@en[[[Host:]]]] や
[CODE(HTTP)@en[[[Date:]]]] などを先に送信するのが[RUBYB[良い習慣]@en[good practice]]とされています。
[SRC[>>12]]

;; [52] 別の名前の[[ヘッダー]]の順序を[[串]]が入れ替えることは仕様上禁止はされていないようですが、普通は入れ替えないものと思われます。

;; [53] [[ライブラリー]]や[[フレームワーク]]の類は[[ヘッダー]]の一覧を順序を保持できない[[ハッシュ]]や[[連想配列]]のような[[データ構造]]に変換することがあります。
ですから[[送信者]]は[[ヘッダー]]の順序に意味を持たせることができません。

* 同名ヘッダー

[28] [[送信者]]は、[[欄値]]全体が[[リスト]] ([CODE[#]])
として定義されている場合や、特に認められている場合を除き、
同名の[[ヘッダー]]を複数[[生成]]しては[['''なりません''']] [SRC[>>12]]。

[EG[
[30] 例えば [CODE(HTTP)@en[[[Set-Cookie:]]]] [[ヘッダー]]は、[[リスト]]として定義されていませんが、
複数含めることが認められています。
]EG]

[29] [[受信者]]は、同名の[[ヘッダー]]を、出現順に値を [CODE[[[,]]]]
で区切って連結することでまとめて構いません。 [SRC[>>12]]

;; [31] しかし[[リスト]]以外の構文を持つ[[ヘッダー]]は、この連結によって意味が変わってしまうことがあります。

[58] [CODE(HTTP)@en[[[Set-Cookie:]]]] は連結することで意味が変わってしまうので、
連結する[['''べきではない''']]とされています。

[100] [CODE(HTTP)@en[[[Cookie:]]]] は [[HTTP/2]] で例外的に複数指定することが認められており、
特別な連結の方法も定義されています。

;; [CODE(HTTP)@en[[[Cookie:]]]] を参照。

[59] [CODE(HTTP)@en[[[Default-Style:]]]] はその構文や適合性が明確に規定はされていませんが、
値に [CODE(HTTP)[[[,]]]] が含まれても特別な意味を持たない一方で、
複数[[ヘッダー]]を指定した場合の処理が規定されているため、
[CODE(HTTP)[[[,]]]] で連結すると意味が異なってしまいます。

[97] 一般に、元の状態では構文的に正しくない複数の同名の[[ヘッダー]]の値を連結することで、
構文的に正しくなり、連結したかどうかによって異なる処理がなされてしまう場合があり得ます。
[[受信者]]によって違った解釈をされ得るものは、[[セキュリティー]]ホールとして攻撃に使われる虞があります。

;; [32] 従って、 [[HTTP]] 仕様は [CODE[[[,]]]] による連結を認めていますが、
現実には無条件で [CODE[[[,]]]] によって連結することは [[Web互換]]ではありません。

;; [33] にも関わらず、[[プログラミング言語]]や[[ライブラリー]]によっては連結した後の値しか[[プログラム]]に提供していないことがあります。

[440] [[CGI]] では[[ヘッダー]]を[[メタ変数]]にする時に、同じ名前の[[ヘッダー]]が複数あれば
[CODE[[[,]]]] により連結することになっています。これは[[ヘッダー]]の種類に関わらず適用されます。

[40] [[RFC 7231]] は[[ヘッダー]]の値が1つか[[リスト]]か、
[[リスト]]でない場合に複数の[[ヘッダー]]が指定された時どうする処理するべきかを[[ヘッダー]]の仕様書が明記することを検討するよう求めています [SRC[>>39]]。

;; [41] なぜか明記することを要求ではなく、明記することを検討するよう要請しているに過ぎません。
そして当の [[RFC 723x]] は基本的にそれを明記していません。

[443] [CODE(HTTP)@en[[[Vary:]]]] [[ヘッダー]]は構文が [CODE[#]] を使って定義されていますが、
それとは別に [CODE[[[*]]]] という値も認められていて、「欄値全体が [CODE[#]]」
という条件を満たしませんから、複数指定できません。

[57] [[RFC 4236]] は、 [[RFC 2616]] では拡張ヘッダーは同名で複数含めることが認められていないとして、
[[OPES]] に未対応の [[HTTP]] 串は動作しないかもしれないと主張しています [SRC[>>56]]。
[[RFC 2616]] の何を根拠としているのかは不明ですし、 [[RFC 723x]] にはそのような制限はありません。

[REFS[
- [56] [CITE@en[RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES)]] ([TIME[2014-09-22 20:05:44 +09:00]] 版) <https://tools.ietf.org/html/rfc4236#section-4>
]REFS]

[98] [[WebSocket handshake]] で使われる[[ヘッダー]]の一部は、
[[要求]]と[[応答]]のいずれであるかによって、
複数指定できるかどうかが異なります。

[445] [[ヘッダー]]を複数指定できるかどうかは、 >>444 の JSON データファイルの
[CODE[multiple]] フラグで確認できます。

[REFS[
- [444] [CITE@en[data-web-defs/headers.txt at master · manakai/data-web-defs]] ([TIME[2014-09-01 12:55:03 +09:00]] 版) <https://github.com/manakai/data-web-defs/blob/master/doc/headers.txt>
]REFS]

* 串

[435] [[串]]は、通信連鎖の端点や[[資源]]の状態や選択された[[表現]] ([[payload]] 以外)
についての情報を提供する[[ヘッダー]]については、
特に認められている場合やプライバシーやセキュリティーのため必要な場合を除き、
変更する[['''べきではありません''']] [SRC[>>434]]。

;; [436] 具体的に何のことを指しているのか不明です。

[45] [[HTTP]] の仕様上は >>435 のような限定的な要件しか示されていますが、
実用上、[[串]]は、[[ヘッダー]]の定義上求められている場合と[[変形]]のために必要な場合を除き、
[[ヘッダー]]を追加したり、削除したりするべきではないと思われます。

[EG[
[46] 例えば [[IANA]] に登録されていない[[ヘッダー]]をすべて削除してしまうような[[串]]は、
[[HTTP]] 仕様に明確には違反していませんが、 [[Web互換]]ではありません。
広く利用されているのになぜか [[IANA]] には登録されていない[[ヘッダー]]や、
特定の [[Webサイト]]で[[鯖]]と[[クライアント]]上の[[スクリプト]]との間の情報交換に使う独自の[[ヘッダー]]などが削除されたり改変されたりする[[串]]は実用的ではありません。
]EG]

;; [50] [[キャッシュ項目]]も参照。

* CGI

[2] [[CGI]] においては、[[要求メッセージ]]に含まれる[[HTTPヘッダー]]は
[CODE(CGI)@en[[[HTTP_*]]]] [[メタ変数]]群によって[[鯖]]から[[CGIスクリプト]]に伝達されます。

[48] また[[応答メッセージ]]に含まれるべき[[HTTPヘッダー]]は、
[[HTTPヘッダー]]とほぼ同等の[[CGIヘッダー]]によって[[CGIスクリプト]]から[[鯖]]に伝達されます。

;; [49] 詳しくは [CODE(CGI)@en[[[HTTP_*]]]]、[[CGIヘッダー]]を参照。

* FCAST

[63] [[FCAST]] でも [[HTTPヘッダー]]が[[メタデータ]]の記述方法として採用されています 
[SRC[>>62]]。実装はこれに対応しなければ[['''なりません''']] [SRC[>>66]]。

;; [64] [[メタデータ]]の記述方法として他の方法も選べるようになっていますが、
[[FCAST]] の [[RFC]] で唯一規定されている方式が [[RFC 2616]] [[HTTP/1.1]]
の方法となっています。

[65] ただし [[UTF-8]] で[[符号化]]された[[テキスト]]とされています [SRC[>>62]]。
[[RFC 2616]] では [[HTTPヘッダー]]は [[ISO-8859-1]] とされていますが、
両者の関係は明確にはなっていません。

;; [67] [[FCAST]] も参照。

* 歴史

[68] [[HTTP/0.9]] 時代には [[HTTPヘッダー]]は存在していませんでしたが、
[[HTTP/1.0]] で [[MIME]] (風なもの) が採用された時に
[[RFC 822ヘッダー]]も輸入されてきました。

[69] 元々は [[RFC 822]] や [[MIME]] と異なる[[ヘッダー]]の仕組みを意図的に導入しようとしたわけではなく、
[[HTTP]] が [[MIME]] の[[応用]]の一つとなることを意図していたようではありますが、
[[電子メール]]と [[HTTP]] で実装が共通化されることもほとんどあるわけではなく、
次第に実装も仕様も乖離していったようです。

[70] そのような経緯から、一部の[[ヘッダー]]は[[電子メール]]や [[MIME]] と [[HTTP]]
で共通になっています。しかしその多くは構文や意味が細部では異なっています。
また同名の[[ヘッダー]]の処理や[[非ASCII文字]]の取り扱いなどで、 [[HTTP]]
は独自の規定を設けるようになりました。

[71] 結局 [[HTTP]] と[[電子メール]]は[[ヘッダー名]]の [[IANA登録簿]]を共有するくらいで、
[[ヘッダー]]の共通の構文も個別の構文も全く異なるものとなっています。
([[IANA登録簿]]も同じ一覧表に掲載されているだけで、別の[[プロトコル]]としての登録になっています。)

[REFS[
- [43] [CITE@en-US[MFSA 2006-33: HTTP response smuggling]] ([TIME[2014-10-21 03:53:24 +09:00]] 版) <https://www.mozilla.org/security/announce/2006/mfsa2006-33.html>
]REFS]

[1] [[HTTP]] の[[頭欄]]は4つに分類できます。
=[[一般頭欄]] (general-header fields)
=[[要求頭欄]] (request-header fields)
=[[応答頭欄]] (response-header fields)
=[[実体頭欄]] (entity-header fields)

[3] HTTP の頭欄の順序には指定はありません。
とはいえ、 [[RFC1945]], [[RFC2068]], [[RFC2616]] は「良い習慣」
(“good practice”) である順序を述べています。種類別に >>1
の順序で並べるのが良いそうです。 (種類ごとの順序は決められていません。
もし [[ABNF]] 構文の登場順にするとすれば、アルファベット順になります。)

[4] ''HTTP Response Headers'' <http://msdn.microsoft.com/workshop/author/dhtml/reference/constants/response_headers.asp>

[[M$]] が知っているらしい「応答頭欄」の一覧です。
M$ 的には[[応答]]で帰ってくる欄は全て応答頭欄というらしいです。
単なる一覧であって簡単な説明しかありません。

[[Site-Enter:]] のような独自拡張欄は載っていません。

怪しげな欄を抜き出してみると:

:CONTENT-TRANSFER_ENCODING:
:ECHO-HEADERS:Not implemented.
:ECHO-HEADERS-CRLF:Not implemented.
:ECHO-REPLY:Not implemented.
:ECHO-REQUEST:Not implemented.
:ORIG-URI:
:RAW-HEADERS:All the headers returned by the server. Each header is terminated by "\0". An additional "\0" terminates the list of headers.
:RAW-HEADERS-CRLF:All the headers returned by the server. Each header is separated by a carriage return/line feed (CR/LF) sequence.
:STATUS-CODE:Status code returned by the server. For a list of possible values, see HTTP Status Codes.
:STATUS-TEXT:Any additional text returned by the server on the response line.
:VERSION:Last response code returned by the server.

リンクがある [[wininet]] 系の関数で指定する値も含めているのかもしれませんが。

他にも [[Cookie:]] 欄が載っているとか。 WinIE からサーバーに [[Cookie]]
発行するんでしょうか?

- [5] 「[VAR[foo]]'' '':」のように [CODE(HTTP)[:]] の前に [[WSP]] が入っていると扱えない [[UA]] があるので注意が必要です。
- [6] ''Nonstandard HTTP Headers'' <http://web.archive.org/web/20020610043404/http://www.dais.is.tohoku.ac.jp/~kabe/WWW/nonstdhdr.html>: 有名な『[[UserAgent]] についてのたわごと』の人が書いたメモ。

[60] [DFN[[[RFC 4229]]]] は既存の[[HTTPヘッダー]]を[[IANA登録簿]]に登録されています。
登録時の「状態」は次のように決めているようです。
[FIG(list)[
- [[標準化過程RFC]] や [[W3C勧告]]のものは「[[標準]]」
- [[情報提供RFC]] や [[W3C Note]] のものは「[[情報提供]]」
- [[I-D]] および [[HTTP92]] のものは「[[provisional]]」
- [[W3C WG]] のものは「[[非推奨]]」
]FIG]

[61] [[I-D]] はいくつかだけ選ばれていて、登録対象になっていないものも多々ありますが、
どのように選択したのか不明です。また [[IETF]] と [[W3C]]
以外の標準化団体等の[[ヘッダー]]や、広く用いられていても [[I-D]]
などになっていない[[ヘッダー]]はまったく含まれていません。

[8] [CITE[URLRequestHeader - Adobe ActionScript® 3 (AS3 ) API Reference]]
( ([TIME[2014-02-19 08:18:03 +09:00]] 版))
<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLRequestHeader.html>

[9] [CITE[IRC logs: freenode / #whatwg / 20140610]]
( ([TIME[2014-06-11 15:22:06 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20140610>

[10] [CITE[Rework all things request headers · 35b2c8b · whatwg/fetch]]
( ([TIME[2014-06-13 15:03:38 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/35b2c8b42797e1b2bc8e97f204aaf7c618599202>

[11] [CITE[Align with new Fetch header terminology and unsafe request flag · 6766628 · whatwg/xhr]]
( ([TIME[2014-06-13 15:03:59 +09:00]] 版))
<https://github.com/whatwg/xhr/commit/676662852dbb08836f3697f293484a78167938bf>

[441] [CITE[Illustrate how headers are (soon to be) divided in the platform · a6b39f5 · whatwg/fetch]]
( ([TIME[2014-08-01 07:02:33 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/a6b39f5bbc8163f5336c4c384d62480c5003bd5e>

[442] [CITE[Clarify header ideas a bit. Still not great. https://github.com/slightly... · 137ff3d · whatwg/fetch]]
( ([TIME[2014-08-02 07:30:33 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/137ff3df74d0bb5cbc4aadbbdceb9169d30c3f36>

[448] [CITE@en[RFC 3507 - Internet Content Adaptation Protocol (ICAP)]]
( ([TIME[2014-06-08 07:17:07 +09:00]] 版))
<http://tools.ietf.org/html/rfc3507#section-4.3>

[449] [CITE@en[draft-aranda-dispatch-q4s-02 - The Quality for Service Protocol]]
( ([TIME[2014-07-28 09:14:06 +09:00]] 版))
<http://tools.ietf.org/html/draft-aranda-dispatch-q4s-02#section-4>

[450] [CITE@en[draft-reschke-http-jfv-00 - A JSON Encoding for HTTP Header Field Values]]
( ([TIME[2014-10-16 11:48:14 +09:00]] 版))
<http://tools.ietf.org/html/draft-reschke-http-jfv-00>


[451] [CITE@en[RFC 4037 - Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core]]
( ([TIME[2014-10-26 15:20:25 +09:00]] 版))
<https://tools.ietf.org/html/rfc4037#section-3.1>

[FIG(quote)[
[FIGCAPTION[
[72] [CITE@en-GB-x-hixie[HTML Standard]]
([TIME[2015-03-05 09:33:40 +09:00]] 版)
<https://html.spec.whatwg.org/#concept-http-equivalent-headers>
]FIGCAPTION]

> The HTTP headers are equivalent to fields in other protocols that have the same basic meaning. For example, the HTTP authentication headers are equivalent to the authentication aspects of the FTP protocol.

]FIG]