[17] [[HTTP]] における[DFN[[RUBYB[[[ヘッダー]]]@en[header]]]]は、 当該[[メッセージ]]の解釈や処理の方法に関する情報を入れる欄です。 [[ヘッダー]]は[[名前]] ([[欄名]]) と値 ([[欄値]]) の組です。 [[メッセージ]]には任意の個数[[ヘッダー]]を含められます。 [18] [[HTTP]] 仕様書では[[ヘッダー]]は[DFN[[RUBYB[[[頭欄]]]@en[header field]]]] ([DFN[[[ヘッダーフィールド]]]]) と呼ばれます。 一般的には、また [[HTTP]] 以外の多くの [[Web]] 関連仕様では、単に[[ヘッダー]]と呼ばれています。 ;; [19] 「header field」という用語は [[HTTP]] が影響を受けた [[RFC 822]] などの[[電子メール]]仕様の用語に由来しますが、[[電子メール]]においても一般的には[[ヘッダー]]と呼ばれています。 「header field」全体の集合については、[[ヘッダー部]] ([[ヘッダーリスト]]) を参照してください。 * 仕様書 [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]] 版) ''' - [434] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [39] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) - [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]] 版) - [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]] 版) - [73] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) ]REFS] * 意味 [15] [[ヘッダー]] ([[ヘッダー欄]]) は、[[ヘッダー名]]と[[ヘッダー値]]で構成されます [SRC[>>12]]。 [16] [[ヘッダー名]]は、対応する[[ヘッダー値]]に対する[[名札]]となるもの [SRC[>>12]] であり、[[ヘッダー値]]の構文と意味は[[ヘッダー名]]により決まります。 [SEE[ [[ヘッダー名]]、[[ヘッダー値]] ]] [432] [[HTTP]] においては[[ヘッダー]]の値が[[空文字列]]であることと、 [[ヘッダー]]が指定されていないことは同義ではありません。また[[空文字列]]は非推奨でも何でもなく、 定義上[[空文字列]]であることが要求されている場面もあります。 [54] また、[[ヘッダー]]の値が [CODE[0]] という文字列となることもあります。 ;; [55] [[空文字列]]や [CODE[0]] を[[偽]]として扱う[[プログラミング言語]]で処理する際には注意が必要です。 * テキスト形式メッセージ (HTTP/1.x) におけるヘッダー [76] [[ヘッダー]]は、[[欄名]]、 [CODE(HTTP)[[[:]]]]、[[欄値]]の順に指定します [SRC[>>12]]。 [75] [[欄値]]の前後には[[空白]] ([CODE(ABNF)[[[OWS]]]]) を入れることができます [SRC[>>12]]。 [FIG(railroad)[ = [[字句]] = [CODE[[[:]]]] = [[OWS]] = [[欄値]] = [[OWS]] ]FIG] [77] [[ヘッダー]]の直後には、必ず [[CRLF]] が必要です。 [78] [[ヘッダー]]は、[[ヘッダー部]]や[[トレーラー部]]に任意の個数、指定できます。 ** 構文解析 [85] [SEE[ [[HTTPの構文解析]] ]] [35] [[HTTPメッセージ]]全体としての[[構文解析]]では、 [[ヘッダー]]の名前と値の構造までは[[構文解析]]しますが、 [[欄値]]は解釈が必要になるまで[[構文解析]]しないのが普通です。 [SEE[ [[HTTPメッセージ]]の[[構文解析]]の項 ]] [90] [[IE]] と [[Chrome]] では、 [[CR]], [[LF]], [[CRLF]] が[[改行]]とみなされます。 [[Firefox]] では、 [[LF]], [[CRLF]] が[[改行]]とみなされます。 [TIME[2015-07-29T14:40:06.400Z]] [101] ただし[[ヘッダー部]]全体の末尾は、 [[LF]] か [[CRLF]] が2組なければならないようです。 ([[IE]] では [[CR]] の連続 + [[LF]] も可。) [TIME[2015-07-29T15:27:23.300Z]] [95] (少なくても [CODE(DOMm)@en[[[getAllResponseHeaders]]]] では) すべての[[ヘッダー]]の順序が保存されているようです。 ただし [[Chrome]] で[[空白]]を含む[[ヘッダー名]]のものはなぜか先頭に集められるようです。 [TIME[2015-07-29T14:55:02.700Z]] [99] [[Chrome]] では、それ以外でも一部の[[ヘッダー]]の順序が入れ替わることがありますが、 正確な条件は不明です。 [TIME[2015-08-04T04:07:13.800Z]] [36] [[欄名]]と [CODE(char)[[[:]]]] の間には[[空白]]は認められていません。 [[鯖]]は、[[空白]]がある場合 [CODE(HTTP)[[[400]]]] [[応答]]を返して拒絶しなければ[['''なりません''']]。 [[串]]は、[[下流]]に[[転送]]する前に[[空白]]を削除しなければ[['''なりません''']]。 [SRC[>>12]] ;; [44] 歴史的に[[空白]]の扱いが異なる実装があったため、[[セキュリティー]]上の問題を引き起こしたことがありました [SRC[>>43]]。 ;; [79] [[クライアント]]はどうしたら良いのでしょうか... 一貫性をもたせるなら、[[クライアント]]も[[プロキシ]]も、みなエラーとして扱うべき気がしますが... [81] [[Chrome]]、[[IE]]、[[Firefox]] は (少なくても [[XHR]] では) [CODE[:]] が含まれず[[空白]]で始まらない行や [CODE[:]] で始まる行を無視します。 [TIME[2015-07-29T14:27:32.600Z]] [86] [[Chrome]] は、 [CODE[:]] の前に [CODE(char)@en[[[SP]]]] や [CODE(charname)@en[[[HTAB]]]] があれば、すべて削除します。 [[IE]] は、[[空白]]まで含めて[[ヘッダー名]]とみなします。 [[Firefox]] は、その[[ヘッダー]]全体を無視します。 [TIME[2015-07-29T14:25:54.200Z]] [80] [[Chrome]] と [[IE]] では、 ([[XHR]] [CODE(DOMm)@en[[[getAllResponseHeaders]]]] では) [[ヘッダー名]]の[[大文字]]と[[小文字]]が保存されています。 [[Firefox]] では、何らかの範囲で最初に見た[[大文字]]と[[小文字]]の組み合わせに正規化されてしまうようです。 [TIME[2015-07-29T14:52:23.700Z]] [92] [[Chrome]] と [[IE]] では、[[ヘッダー名]]は [CODE[:]] や[[空白]]を除くどんな[[文字]]でも良いようです。 (少なくても [[XHR]] からアクセスできます。) 途中であれば[[空白]]が含まれてもよく、正規化もされません。 [[Firefox]] では、 [[HTTP]] の[[字句]]でなければならないようです。 [TIME[2015-07-29T14:54:13.700Z]] [82] [[IE]] も [[Firefox]] も [[Chrome]] も、 [[開始行]]の次が継続行なら、黙って無視します。 [TIME[2015-07-29T14:41:13.200Z]] [83] それ以外で (少なくても [[XHR]] では) 継続行がある場合、 [[Chrome]] は[[改行]]とその後の [CODE(charname)@en[[[SP]]]]/[CODE(charname)@en[[[HTAB]]]] の列を1つの [CODE(charname)@en[[[SP]]]] に置き換えます。 [[Firefox]] は[[改行]]だけを除去します。 [[IE]] は [CODE(DOMm)@en[[[getResponseHeader]]]] で[[改行]]前までしか返しません。 [TIME[2015-07-29T14:32:16.600Z]] [84] [[IE]] は[[空白]]のみで構成される行があると、[[ヘッダー部]]の終わりの[[空行]]と誤認します。 [TIME[2015-07-29T14:32:30.00Z]] [37] [[欄値]]の前後の [[OWS]] は、[[欄値]]の一部ではなく、 [[構文解析]]の際に削除します [SRC[>>12]]。 [87] [[Chrome]] も [[Firefox]] も、値の前後の [CODE(charname)@en[[[SP]]]]/[CODE(charname)@en[[[HTAB]]]] を除去します。これは継続行の改行の除去後に行われます。 [TIME[2015-07-29T14:37:21.500Z]] [88] [[IE]] は値の後の [CODE(charname)@en[[[SP]]]]/[CODE(charname)@en[[[HTAB]]]] と、値の前の [CODE(charname)@en[[[SP]]]] を除去します。 [TIME[2015-07-29T14:37:42.300Z]] [89] [[Firefox]] は、 (少なくても [[XHR]] では) [[空白]]の除去後に値が空になると、 その[[ヘッダー]]全体を無視します。 [[Chrome]] や [[IE]] ではそんなことはありません。 [TIME[2015-07-29T14:38:45.400Z]] [91] [[Chrome]] では[[ヘッダー名]]と値、[[Firefox]] では値の[[非ASCII文字]]も、 (少なくても [[XHR]] では) そのまま U+0080-U+00FF として返されるようです。 [TIME[2015-07-29T15:07:30.600Z]] [96] [[IE]] では[[ヘッダー名]]と値の[[非ASCII文字]]は、 (少なくても [[XHR]] では) おそらくシステムの [[ANSI文字セット]]で[[復号]]したものを返すようです。 ([[UTF-8]] の[[文書]]でも、[[日本語]]環境では [[CP932]] で解釈されています。) [TIME[2015-07-29T15:09:38.700Z]] [109] [[Apache]] は [CODE[:]] が含まれず[[空白]]から始まらない行が[[ヘッダー部]]にあると、 [CODE[400]] [[応答]]を返します。 [[nginx]] は無視して処理を続けます。 [TIME[2016-09-09T08:40:15.600Z]] [110] [[Apache]] は[[ヘッダー部]]の終わりの空行の前に[[接続][HTTP接続]]が閉じられると、 [CODE[400]] [[応答]]を返します。 [[nginx]] は通常通り処理を続けます。 [TIME[2016-09-09T09:13:05.200Z]] * バイナリー形式メッセージ (HTTP/2) におけるヘッダー [74] [[HTTP/2]] には、 [[HTTP/1.1]] と共通の通常の [[HTTPヘッダー]]と、 [[HTTP/1.1]] の[[開始行]]に相当する[[疑似ヘッダー]]があります。 [113] いずれの[[ヘッダー]]も、[[ヘッダーリスト]]を構成します。 [[ヘッダーリスト]]は、 [[HPACK]] により[[ヘッダーブロック]]として[[符号化]]し、 必要なら[[ヘッダーブロック素片]]として分割し、 [CODE(HTTP)@en[[[HEADERS]]]] や [CODE(HTTP)@en[[[PUSH_PROMISE]]]] や [CODE(HTTP)@en[[[CONTINUATION]]]] の[[フレーム]]の [[payload]] として送信されます [SRC[>>73]]。 ;; [[ヘッダーブロック]]や[[HPACK]]、[[ヘッダー名]]、[[ヘッダー値]]も参照。 * 文脈 [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]] が、使って良い文脈を完全には明記していません。 使ってはいけない状況や使わなければならない文脈は明記されていることが多いですが、 その他の多くは曖昧にされています。 * 処理 [38] [[欄値]]には[[行折り畳み]]が含まれていることがあります。 その処理については、[[欄値]]、[[行折り畳み]]の項を参照してください。 [401] [[鯖]]は、処理したい長さより長い[[ヘッダー]]のある[[要求]]を受信した時は、 適切な [CODE(HTTP)[[[4xx]]]] [[状態符号]]で応答しなければ[['''なりません''']] [SRC[>>12]]。 ;; [404] [CODE(HTTP)[[[431]]]] が適当そうですが、限定されていないのには何か意味があるのでしょうか? ([[HTTP]] 本体である [[RFC 723x]] に含まれていないという形式的な理由かもしれませんが、 仕様書はもっと実装者に有用な情報を提供してほしいものです...) [402] [[クライアント]]は、処理したい長さより長い[[ヘッダー]]のある[[応答]]を受信した時は、 それによって[[メッセージ]]の[[フレーム付け]]や[[応答]]の意味が変わってしまわない限り、 当該[[ヘッダー]]を除去したり途中で切ったりしても構いません。 [SRC[>>12]] ;; [403] 意味が変わってしまう場合にどうするべきかは明記されていません。 [26] [[鯖]]は、[[要求]]の[[ヘッダー]]全体を[[受信]]するまで[[対象資源]]に[[要求]]を適用しては[['''なりません''']] [SRC[>>12]]。 * ヘッダーの種類 [20] [[ヘッダー]]の種類は[[ヘッダー名]]により識別されます。 [[ヘッダー]]は、 [[HTTP]] 本体仕様で定義されている他、 追加の[[ヘッダー]]が随時追加されています。 [7] [[HTTPヘッダー]]には、 [[RFC]] で規定されているもの、 実装依存のものなど沢山の種類があります。 [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:]]]] [[ヘッダー]]による指定や[[串]]の個別の設定など、 他の規定により[[転送]]しなくて良い場合もあります。) [SEE[ >>435 ]] [23] [[串]]以外の[[受信者]]は、認識できない[[ヘッダー]]を無視する[['''べきです''']] [SRC[>>12]]。 ;; [51] ここでいう「無視」は、それによって特別な処理をしないことを指しています。 例えば[[Webブラウザー]]は、 [[XHR]] によって得られた[[応答]]に ([[Webブラウザー]]が) 知らない[[ヘッダー]]が含まれていたら、 それを [[XHR]] の [[API]] によって[[スクリプト]]に提供することが求められます (「無視」して削除してはいけません)。 [FIG(short list)[ [124] [[HTTPヘッダー]]の分類 - [[privileged no-cors request-header name]] ]FIG] [REFS[ - [438] [CITE[Message Headers]] ([TIME[2014-06-13 18:50:11 +09:00]] 版) -- [135] 旧登録簿 (既に [[HTTPヘッダー]]は削除済み) - [136] [CITE[Hypertext Transfer Protocol (HTTP) Field Name Registry]], [TIME[2024-10-08T00:05:23.000Z]], [TIME[2024-11-17T04:40:22.011Z]] - [437] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) ]REFS] [137] [[IANA登録簿]]はかつては[[インターネットメール]]や[[インターネットニュース]]や[[MIME]] と共通でしたが、今は [[HTTP]] 独自のものになっています。 ;; [138] 強い影響は受けたものの共通点より違いの方が多い[[インターネットメッセージ]]とは共通なのに、 [[HTTP]] から派生して比較的違いが少ない [[RTSP]] や [[SIP]] の登録簿は共通化されていないという、 不思議な状況でした。 ;; [139] 開発の歴史的経緯から [[IETF]] 方面で[[インターネットメール]]系の人々が [[HTTP]] にも関心とある程度の影響力を持っていた (がより新しい時代になって開発された [[RTSP]] や [[SIP]] は[[インターネットメール]]や [[HTTP]] と人脈的な関係が薄かった) という、標準化現場の構図がそのまま反映されてしまったものと推測されます。 [140] 登録簿分離のタイミングなのかわかりませんが、 以前登録されていたはずのものがいくつか消えているみたいです。 仕様書もないのに実装だけされていたものがいくつか気まぐれに(?)予備登録されていたようで、 そういうのが消えているように見えます。 ** HTTP ヘッダーの一覧 [SEE[ [[HTTPヘッダーの一覧]] ]] * ヘッダーの順序 [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] [[ライブラリー]]や[[フレームワーク]]の類は[[ヘッダー]]の一覧を順序を保持できない[[ハッシュ]]や[[連想配列]]のような[[データ構造]]に変換することがあります。 ですから[[送信者]]は[[ヘッダー]]の順序に意味を持たせることができません。 [127] [CODE[getAllResponseHeaders]] では特別な順序に[[整列]]されます。 [SEE[ [[getAllResponseHeaders]] ]] * 同名ヘッダー [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]] で例外的に複数指定することが認められており、 特別な連結の方法も定義されています。 [SEE[ [CODE(HTTP)@en[Cookie:]] ]] [59] [CODE(HTTP)@en[[[Default-Style:]]]] はその構文や適合性が明確に規定はされていませんが、 値に [CODE(HTTP)[[[,]]]] が含まれても特別な意味を持たない一方で、 複数[[ヘッダー]]を指定した場合の処理が規定されているため、 [CODE(HTTP)[[[,]]]] で連結すると意味が異なってしまいます。 [97] 一般に、元の状態では構文的に正しくない複数の同名の[[ヘッダー]]の値を連結することで、 構文的に正しくなり、連結したかどうかによって異なる処理がなされてしまう場合があり得ます。 [[受信者]]によって違った解釈をされ得るものは、[[セキュリティー]]ホールとして攻撃に使われる虞があります。 ;; [32] 従って、 [[HTTP]] 仕様は [CODE[[[,]]]] による連結を認めていますが、 現実には無条件で [CODE[[[,]]]] によって連結することは [[Web互換]]ではありません。 ;; [33] にも関わらず、[[プログラミング言語]]や[[ライブラリー]]によっては連結した後の値しか[[プログラム]]に提供していないことがあります。 [440] [[CGI]] では[[ヘッダー]]を[[メタ変数]]にする時に、同じ名前の[[ヘッダー]]が複数あれば [CODE[[[,]]]] により連結することになっています。これは[[ヘッダー]]の種類に関わらず適用されます。 [129] [[DOM]] の [CODE[Headers]] [[オブジェクト]]の [CODE[get]] [[メソッド]]は、 複数の[[ヘッダー]]があるとき 「[CODE[[[,]] ]]」 ([CODE[0x2C]] [CODE[0x20]]) で連結して返すと定められています。 [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]] 版) ]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]] 版) ]REFS] * 串 [435] [[串]]は、通信連鎖の端点や[[資源]]の状態や選択された[[表現]] ([[payload]] 以外) についての情報を提供する[[ヘッダー]]については、 特に認められている場合やプライバシーやセキュリティーのため必要な場合を除き、 変更する[['''べきではありません''']] [SRC[>>434]]。 ;; [436] 具体的に何のことを指しているのか不明です。 [45] [[HTTP]] の仕様上は >>435 のような限定的な要件しか示されていますが、 実用上、[[串]]は、[[ヘッダー]]の定義上求められている場合と[[変形]]のために必要な場合を除き、 [[ヘッダー]]を追加したり、削除したりするべきではないと思われます。 [EG[ [46] 例えば [[IANA]] に登録されていない[[ヘッダー]]をすべて削除してしまうような[[串]]は、 [[HTTP]] 仕様に明確には違反していませんが、 [[Web互換]]ではありません。 広く利用されているのになぜか [[IANA]] には登録されていない[[ヘッダー]]や、 特定の [[Webサイト]]で[[鯖]]と[[クライアント]]上の[[スクリプト]]との間の情報交換に使う独自の[[ヘッダー]]などが削除されたり改変されたりする[[串]]は実用的ではありません。 ]EG] [50] [SEE[ [[キャッシュ項目]] ]] * CGI [2] [[CGI]] においては、[[要求メッセージ]]に含まれる[[HTTPヘッダー]]は [CODE(CGI)@en[[[HTTP_*]]]] [[メタ変数]]群によって[[鯖]]から[[CGIスクリプト]]に伝達されます。 [48] また[[応答メッセージ]]に含まれるべき[[HTTPヘッダー]]は、 [[HTTPヘッダー]]とほぼ同等の[[CGIヘッダー]]によって[[CGIスクリプト]]から[[鯖]]に伝達されます。 [SEE[ [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]] とされていますが、 両者の関係は明確にはなっていません。 [SEE[ [[FCAST]] ]] * 関連 [133] [[CATPヘッダー]] * 歴史 [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]] 版) ]REFS] [141] [[HTTPメッセージ]]は、[[頭部]]と[[本体]]の2部で構成されています。 [[頭部]]には、[[本体]]に関する[[メタ情報]]や[[HTTP]]通信に関する制御情報などを[DFN[[RUBY[頭欄] [かしららん] @en[header field]]]]の集合体として記述します。 個々の頭欄は、[[欄名]]と[[欄本体]]の組で構成されます。 [142] [[欄名]]によって識別される[[頭欄]]の種類は、 [[HTTP]]本体規格で規定されている他、 各種周辺規格で追加のものが定義されています。 [143] '''頭欄の分類''': [[頭欄]]は、使われる場所と意味によって4種類に分けられます。 =[[一般頭欄]] (general-header fields) [[HTTP]]通信一般に関わる[[頭欄]]で、多くは[[要求]]でも[[応答]]でも使用されます。 =[[要求頭欄]] (request-header fields) [[HTTP]][[要求]]に関する[[頭欄]]です。 =[[応答頭欄]] (response-header fields) [[HTTP]][[応答]]に関する[[頭欄]]です。 =[[実体頭欄]] (entity-header fields) [[HTTP]][[実体]] (or [[実現値]]) に関する[[頭欄]]です。 [[要求]]でも[[応答]]でも使われます。 [3] HTTP の頭欄の順序には指定はありません。 とはいえ、 [[RFC1945]], [[RFC2068]], [[RFC2616]] は「良い習慣」 (“good practice”) である順序を述べています。種類別に >>1 の順序で並べるのが良いそうです。 (種類ごとの順序は決められていません。 もし [[ABNF]] 構文の登場順にするとすれば、アルファベット順になります。) [4] ''HTTP Response Headers'' [[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'' : 有名な『[[UserAgent]] についてのたわごと』の人が書いたメモ。 [FIG(quote)[ [145] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 4.2 Message Headers > HTTP header fields, which include [DEL[General-Header (Section 4.3)]] [INS[general-header (section 4.5)]], [DEL[Request-Header (Section 5.2)]] [INS[request-header (section 5.3)]], [DEL[Response-Header (Section 6.2)]] [INS[response-header (section 6.2)]], and [DEL[Entity-Header (Section 7.1)]] [INS[entity-header (section 7.1)]] fields, follow the same generic format as that given in Section 3.1 of RFC 822 [DEL[ [7] ]] [INS[ [9] ]]. Each header field consists of a name followed [DEL[immediately]] by a colon (":")[DEL[, a single space (SP) character,]] and the field value. Field names are case-insensitive. [INS[The field value [DEL[may]] [INS[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[DEL[, though this is not recommended]]. [INS[Applications [DEL[SHOULD]] [INS[ought to]] follow "common form"[INS[, 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.]] [DFN[HTTP 頭欄]]は、[[一般頭欄]], [[要求頭欄]], [[応答頭欄]], [[実体頭欄]]を含みますが、 [[RFC822]] の3.1節にある同じ一般書式に従います。 各頭欄は名前、それに[DEL[すぐに]]続くコロン ([CODE(HTTP)[:]])、[DEL[1つの[[間隔]] ([[SP]]) 文字、]]欄値から成ります。 欄名は大文字・小文字を区別しません。[INS[欄値の前には任意の量の [CODE(ABNF)[[[LWS]]]] があって'''構いません'''。しかし [CODE(ABNF)[[[SP]]]] 1つが好ましいです。]] 頭欄は、それぞれの余分な行に最低1つの [CODE(ABNF)[[[SP]]]] または [CODE(ABNF)[[[HT]]]] を入れることで複数行に展開できます。[DEL[ただしこれは推奨しません。]] [INS[応用は、 HTTP 構造体を生成する時に、 [INS[(それが知られているかまたは示されている時には)]]「共通形」に従うべきです。そうしないと、共通形以外のものを受け入れてくれない実装が存在するかもしれません。]] > - [DEL[ HTTP-header = field-name ":" [ field-value ] CRLF]] - [INS[ message-header = field-name ":" [ field-value ] [DEL[CRLF]]]] > - field-name = token - field-value = *( field-content | LWS ) - field-content = [INS[ > [INS[{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. [CODE(ABNF)[field-content]] は最初や最後の [CODE(ABNF)[LWS]]、つまり [CODE(ABNF)[field-value]] の最初の非空白文字の前や最後の非空白文字の後の[[線形空白]]を含みません。 この最初や最後の [CODE(ABNF)[LWS]] は欄値の意味を変えずに削除して'''構いません'''。 [CODE(ABNF)[field-content]] の間に現れる任意の [CODE(ABNF)[LWS]] は欄値を解釈したりメッセージを[[下流]]に転送したりする前に1つの [CODE(ABNF)[SP]] に置換しても'''構いません'''。 ]INS] > The order in which header fields [INS[with differing field names]] are received is not significant. However, it is "good practice" to send [DEL[General-Header]] [INS[general-header]] fields first, followed by [DEL[Request-Header]] [INS[request-header]] or [DEL[Response-Header]] [INS[response-header]] fields[INS[, and ending with]] [DEL[prior to]] the [DEL[Entity-Header]] [INS[entity-header]] fields. どの順序で[INS[名前の異なる]]頭欄を受信したかは重要ではありません。 しかし、一般頭欄を最初に送り、続けて要求頭欄または応答頭欄を実体頭欄の前に送るのが 「[[良い習慣]]」です。 > Multiple [DEL[HTTP-header]] [INS[message-header]] fields with the same field-name [DEL[[INS[{1945,2068}]] may]] [INS[[INS[{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 [DEL[must]] [INS[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. [INS[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.]] 同じ [CODE(ABNF)[field-name]] の複数の [CODE(ABNF)[message-header]] は、その頭欄の [CODE(ABNF)[field-value]] 全体が読点分離並び (つまり [CODE(ABNF)[#([VAR[values]])]]) として定義されているときに、 この場合に限って出現して'''構いません'''。 各後続 [CODE(ABNF)[field-value]] を最初のものに、それぞれ読点で分離して後置することによって、 メッセージの意味を変えずに複数の頭欄を一つの [SAMP(HTTP)[[VAR[field-name]]: [VAR[field-value]]]] 組に結合することが可能でなければ'''なりません'''。 [INS[ 注: 注記なき追加・削除は 1945→2068 の差分。 追加部分の中の追加・削除は 2068→2616 の差分。 ]INS] ]FIG] -*-*- [1] '''頭欄の種類''': [[頭欄]]は、[[IETF]]の[[RFC]]で規定されているもの、 他の[[標準化団体]]が規定したもの、 規定なしで勝手に使われているものなど色々あります。 長らくこの状況で放置されてきましたが、[[RFC 3864]] (2004年、[[BCP 90]]) によって[[IANA]]登録手続きが成立し、[[RFC 4229]] (2005年) でこれまでに標準化されたものが登録されました。 ;; - [[IANA]] 登録簿: [CITE@en[IANA | Message Header Messages]] - [[RFC 3864]] (登録手続き、[[IETF]] [[BCP 90]]) , - [[RFC 4229]] (初期登録、[[IETF]][[情報提供]]) [60] [DFN[[[RFC 4229]]]] は既存の[[HTTPヘッダー]]を[[IANA登録簿]]に登録されています。 登録時の「状態」は次のように決めているようです。 [FIG(list)[ - [[標準化過程RFC]] や [[W3C勧告]]のものは「[[標準]]」 - [[情報提供RFC]] や [[W3C Note]] のものは「[[情報提供]]」 - [[I-D]] および [[HTTP92]] のものは「[[provisional]]」 - [[W3C WG]] のものは「[[非推奨]]」 ]FIG] [REFS[ - [130] [CITE@en[[[RFC 4229]]: HTTP Header Field Registrations]], [TIME[2021-08-02T11:41:17.000Z]] - [131] [CITE[RFC Errata Report » RFC Editor]], [TIME[2021-08-02T11:44:08.000Z]] ]REFS] [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]] 版)) [9] [CITE[IRC logs: freenode / #whatwg / 20140610]] ( ([TIME[2014-06-11 15:22:06 +09:00]] 版)) [10] [CITE[Rework all things request headers · 35b2c8b · whatwg/fetch]] ( ([TIME[2014-06-13 15:03:38 +09:00]] 版)) [11] [CITE[Align with new Fetch header terminology and unsafe request flag · 6766628 · whatwg/xhr]] ( ([TIME[2014-06-13 15:03:59 +09:00]] 版)) [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]] 版)) [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]] 版)) [448] [CITE@en[RFC 3507 - Internet Content Adaptation Protocol (ICAP)]] ( ([TIME[2014-06-08 07:17:07 +09:00]] 版)) [449] [CITE@en[draft-aranda-dispatch-q4s-02 - The Quality for Service Protocol]] ( ([TIME[2014-07-28 09:14:06 +09:00]] 版)) [450] [[JSONヘッダー値]] [451] [CITE@en[RFC 4037 - Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core]] ( ([TIME[2014-10-26 15:20:25 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [72] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-03-05 09:33:40 +09:00]] 版) ]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] [102] [CITE[nextthing.org » Fun With HTTP Headers]] ([TIME[2015-09-07 11:25:57 +09:00]] 版) [103] [CITE@en[HTTP header representation in Fetch]] ([[Anne van Kesteren]] 著, [TIME[2016-01-19 18:27:06 +09:00]] 版) [144] [CITE[HTTP interoperability - Anne’s Weblog]] ([TIME[2007-10-14 05:05:32 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [104] [CITE@en[Re: HTTP header representation in Fetch]] ([[Honza Bambas]] 著, [TIME[2016-01-20 05:16:55 +09:00]] 版) ]FIGCAPTION] > Merging of certain headers is in Gecko prohibited for security reasons > (injection attacks). We explicitly hard-fail the response when there is > more than one instance of Content-Length, Content-Disposition or > Location. Hence merging e.g. Location is a very bad idea. > Then we have an even wider list of headers that must not be present in a > response more than once, see '''['''1''']'''. We only accept value of the first > presence of such a header, others are silently ignored. Only on those 3 > mentioned above we fail with an error when duplicated. > Headers NOT on the list at '''['''1''']''' are merged to one only, so that upper > layers see them as Header: value1, value2, ... We definitely do this > also for the Set-Cookie header. > return header == nsHttp::Content_Type || > header == nsHttp::Content_Disposition || > header == nsHttp::Content_Length || > header == nsHttp::User_Agent || > header == nsHttp::Referer || > header == nsHttp::Host || > header == nsHttp::Authorization || > header == nsHttp::Proxy_Authorization || > header == nsHttp::If_Modified_Since || > header == nsHttp::If_Unmodified_Since || > header == nsHttp::From || > header == nsHttp::Location || > header == nsHttp::Max_Forwards; ]FIG] [105] [CITE@en[Fix #189: expose headers as a basic map in Headers · whatwg/fetch@42464c8]] ([TIME[2016-01-29 16:50:28 +09:00]] 版) [106] [CITE@en[918764 – '''['''XHR2''']''' Wrong exception: "TypeError" is not "DOMException SyntaxError"]] ( ([TIME[2016-06-07 18:50:10 +09:00]])) [107] [CITE@en[Editorial: extract header sorting and combining]] ( ([[annevk]]著, [TIME[2016-06-07 22:55:09 +09:00]])) [108] [CITE@en[Define get(All)ResponseHeader(s) in terms of Fetch]] ( ([[annevk]]著, [TIME[2016-06-07 23:16:42 +09:00]])) [FIG(quote)[ [FIGCAPTION[ [111] [CITE@en[Web Annotation Data Model]] ([TIME[2017-02-24 02:14:26 +09:00]]) ]FIGCAPTION] > The HTTP request headers to send as a single, complete string. ]FIG] [FIG(quote)[ [FIGCAPTION[ [112] [CITE@en[Web Annotation Data Model]] ([TIME[2017-02-24 02:14:26 +09:00]]) ]FIGCAPTION] > "state": { > "type": "HttpRequestState", > "value": "Accept: application/pdf" > } ]FIG] [114] [CITE@en[Web Annotation Vocabulary]] ([TIME[2017-02-24 02:14:26 +09:00]]) [115] [CITE@en[Selectors and States]] ([TIME[2017-02-24 02:14:26 +09:00]]) [116] [CITE@en[Sort and lowercase header names in getAllResponseHeaders() example]] ([[annevk]]著, [TIME[2017-04-20 18:14:28 +09:00]]) [117] [CITE@en[Editorial: make Request/Response's headers its own concept]] ([[jakearchibald]]著, [TIME[2017-08-10 21:33:51 +09:00]]) [118] [CITE@en[Editorial: Making headers their own property by jakearchibald · Pull Request #575 · whatwg/fetch]] ([TIME[2017-08-11 12:10:27 +09:00]]) [119] [CITE@en[655389 - CRLF Injection and the parsing of HTTP headers]] ([TIME[2017-10-06 15:35:45 +09:00]]) [120] [CITE@en[draft-nottingham-structured-headers-00 - Structured Headers for HTTP]] ([TIME[2017-10-30 21:14:27 +09:00]]) - [[CTA-5004]] [121] [CITE@en[ABNF for metric-value · Issue #12 · w3c/server-timing]] ([TIME[2017-11-03 14:27:21 +09:00]]) [122] [CITE@en[Review request for Server-Timing · Issue #188 · w3ctag/design-reviews]] ([TIME[2017-11-03 14:29:47 +09:00]]) [123] [CITE@en[Fix Origin header and "no-cors" redirects behavior]] ([[annevk]]著, [TIME[2018-05-28 18:17:18 +09:00]]) [125] [CITE@en[Specify identity encoding for range requests]] ([[jakearchibald]]著, [TIME[2018-06-06 16:26:21 +09:00]]) [34] [CITE@en[Define parsing for X-Content-Type-Options: nosniff in detail]] ([[annevk]]著, [TIME[2018-11-01 18:14:30 +09:00]]) [49] [CITE[mnot’s blog: Designing Headers for HTTP Compression]] ([TIME[2019-05-12 10:50:14 +09:00]]) [67] [CITE@en[Define the Content-Type header parser]] ([[annevk]]著, [TIME[2018-11-27 18:47:01 +09:00]]) [126] [CITE@en[Editorial: defining header name sorting]] ([[annevk]]著, [TIME[2019-08-08 18:12:23 +09:00]]) [128] [CITE@en[Command-Line Interface — Streamlink 1.6.0 documentation]] ([TIME[2020-09-30T20:32:48.000Z]], [TIME[2020-10-01T07:49:37.748Z]]) [132] [CITE@en[protocol-registries/http-fields: Registry for HTTP field names (headers and trailers)]] ([TIME[2021-10-30T02:21:21.000Z]]) [134] [CITE@en-US[Deliver Custom Content With CloudFront | AWS News Blog]] ([TIME[2024-02-13T02:40:47.000Z]], [TIME[2024-04-26T11:19:05.020Z]])