[17] HTTP におけるヘッダーは、 当該メッセージの解釈や処理の方法に関する情報を入れる欄です。 ヘッダーは名前 (欄名) と値 (欄値) の組です。 メッセージには任意の個数ヘッダーを含められます。
[18] HTTP 仕様書ではヘッダーは頭欄 (ヘッダーフィールド) と呼ばれます。 一般的には、また HTTP 以外の多くの Web 関連仕様では、単にヘッダーと呼ばれています。
[15] ヘッダー (ヘッダー欄) は、ヘッダー名とヘッダー値で構成されます >>12。
[16] ヘッダー名は、対応するヘッダー値に対する名札となるもの >>12
であり、ヘッダー値の構文と意味はヘッダー名により決まります。
[432] HTTP においてはヘッダーの値が空文字列であることと、 ヘッダーが指定されていないことは同義ではありません。また空文字列は非推奨でも何でもなく、 定義上空文字列であることが要求されている場面もあります。
[76] ヘッダーは、欄名、 :、欄値の順に指定します >>12。
[75] 欄値の前後には空白 (OWS) を入れることができます >>12。
[78] ヘッダーは、ヘッダー部やトレーラー部に任意の個数、指定できます。
[35] HTTPメッセージ全体としての構文解析では、
ヘッダーの名前と値の構造までは構文解析しますが、
欄値は解釈が必要になるまで構文解析しないのが普通です。
[90] IE と Chrome では、 CR, LF, CRLF が改行とみなされます。 Firefox では、 LF, CRLF が改行とみなされます。
[101] ただしヘッダー部全体の末尾は、 LF か CRLF が2組なければならないようです。 (IE では CR の連続 + LF も可。)
[95] (少なくても getAllResponseHeaders では) すべてのヘッダーの順序が保存されているようです。
ただし Chrome で空白を含むヘッダー名のものはなぜか先頭に集められるようです。
[99] Chrome では、それ以外でも一部のヘッダーの順序が入れ替わることがありますが、 正確な条件は不明です。
[36] 欄名と : の間には空白は認められていません。
鯖は、空白がある場合 400
応答を返して拒絶しなければなりません。
串は、下流に転送する前に空白を削除しなければなりません。
>>12
[81] Chrome、IE、Firefox は (少なくても XHR では) : が含まれず空白で始まらない行や : で始まる行を無視します。
[86] Chrome は、 : の前に SP や
HTAB があれば、すべて削除します。
IE は、空白まで含めてヘッダー名とみなします。
Firefox は、そのヘッダー全体を無視します。
[80] Chrome と IE では、 (XHR getAllResponseHeaders では)
ヘッダー名の大文字と小文字が保存されています。 Firefox
では、何らかの範囲で最初に見た大文字と小文字の組み合わせに正規化されてしまうようです。
[92] Chrome と IE では、ヘッダー名は : や空白を除くどんな文字でも良いようです。 (少なくても XHR からアクセスできます。)
途中であれば空白が含まれてもよく、正規化もされません。
Firefox では、 HTTP の字句でなければならないようです。
[82] IE も Firefox も Chrome も、 開始行の次が継続行なら、黙って無視します。
[83] それ以外で (少なくても XHR では) 継続行がある場合、 Chrome は改行とその後の
SP/HTAB の列を1つの
SP に置き換えます。 Firefox は改行だけを除去します。
IE は getResponseHeader で改行前までしか返しません。
[84] IE は空白のみで構成される行があると、ヘッダー部の終わりの空行と誤認します。
[37] 欄値の前後の OWS は、欄値の一部ではなく、 構文解析の際に削除します >>12。
[87] Chrome も Firefox も、値の前後の SP/HTAB
を除去します。これは継続行の改行の除去後に行われます。
[88] IE は値の後の SP/HTAB
と、値の前の SP を除去します。
[89] Firefox は、 (少なくても XHR では) 空白の除去後に値が空になると、 そのヘッダー全体を無視します。 Chrome や IE ではそんなことはありません。
[91] Chrome ではヘッダー名と値、Firefox では値の非ASCII文字も、 (少なくても XHR では) そのまま U+0080-U+00FF として返されるようです。
[96] IE ではヘッダー名と値の非ASCII文字は、 (少なくても XHR では) おそらくシステムの ANSI文字セットで復号したものを返すようです。 (UTF-8 の文書でも、日本語環境では CP932 で解釈されています。)
[109] Apache は : が含まれず空白から始まらない行がヘッダー部にあると、
400 応答を返します。 nginx は無視して処理を続けます。
[110] Apache はヘッダー部の終わりの空行の前に接続が閉じられると、
400 応答を返します。 nginx は通常通り処理を続けます。
[74] HTTP/2 には、 HTTP/1.1 と共通の通常の HTTPヘッダーと、 HTTP/1.1 の開始行に相当する疑似ヘッダーがあります。
[113] いずれのヘッダーも、ヘッダーリストを構成します。
ヘッダーリストは、 HPACK によりヘッダーブロックとして符号化し、
必要ならヘッダーブロック素片として分割し、
HEADERS や PUSH_PROMISE や
CONTINUATION のフレームの payload
として送信されます >>73。
[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] ヘッダーの種類 (ヘッダー名) や要求メッセージ、状態符号その他の文脈により、 それぞれ更に細かい制約があります。 (詳細は各ヘッダーの文脈の項を参照してください。)
[38] 欄値には行折り畳みが含まれていることがあります。 その処理については、欄値、行折り畳みの項を参照してください。
[401] 鯖は、処理したい長さより長いヘッダーのある要求を受信した時は、
適切な 4xx 状態符号で応答しなければなりません >>12。
431 が適当そうですが、限定されていないのには何か意味があるのでしょうか?
(HTTP 本体である RFC 723x に含まれていないという形式的な理由かもしれませんが、
仕様書はもっと実装者に有用な情報を提供してほしいものです...)[402] クライアントは、処理したい長さより長いヘッダーのある応答を受信した時は、 それによってメッセージのフレーム付けや応答の意味が変わってしまわない限り、 当該ヘッダーを除去したり途中で切ったりしても構いません。 >>12
[20] ヘッダーの種類はヘッダー名により識別されます。 ヘッダーは、 HTTP 本体仕様で定義されている他、 追加のヘッダーが随時追加されています。
[7] HTTPヘッダーには、 RFC で規定されているもの、 実装依存のものなど沢山の種類があります。
[21] ヘッダー名については、電子メール等と共通の IANA登録簿があります >>438, >>39。定義されたヘッダーは、 IANA に登録するべきです >>12。
[22] 串は、原則として認識できないヘッダーを転送しなければなりません
>>12。 (Connection: ヘッダーによる指定や串の個別の設定など、
他の規定により転送しなくて良い場合もあります。)
[23] 串以外の受信者は、認識できないヘッダーを無視するべきです >>12。
[137] IANA登録簿はかつてはインターネットメールやインターネットニュースやMIME と共通でしたが、今は HTTP 独自のものになっています。
[140] 登録簿分離のタイミングなのかわかりませんが、 以前登録されていたはずのものがいくつか消えているみたいです。 仕様書もないのに実装だけされていたものがいくつか気まぐれに(?)予備登録されていたようで、 そういうのが消えているように見えます。
[24] 異なる欄名のヘッダー同士の順序は、意味を持ちません >>12。
[27] 同名のヘッダーの順序には意味があります >>12。 串は転送の際にその順序を入れ替えてはなりません >>12。
[25] 制御データを含む Host: や
Date: などを先に送信するのが良い習慣とされています。
>>12
[127]
getAllResponseHeaders
では特別な順序に整列されます。
[28] 送信者は、欄値全体がリスト (#)
として定義されている場合や、特に認められている場合を除き、
同名のヘッダーを複数生成してはなりません >>12。
[30] 例えば Set-Cookie: ヘッダーは、リストとして定義されていませんが、
複数含めることが認められています。
[29] 受信者は、同名のヘッダーを、出現順に値を ,
で区切って連結することでまとめて構いません。 >>12
[58] Set-Cookie: は連結することで意味が変わってしまうので、
連結するべきではないとされています。
[100] Cookie: は HTTP/2 で例外的に複数指定することが認められており、
特別な連結の方法も定義されています。
Cookie:
[59] Default-Style: はその構文や適合性が明確に規定はされていませんが、
値に , が含まれても特別な意味を持たない一方で、
複数ヘッダーを指定した場合の処理が規定されているため、
, で連結すると意味が異なってしまいます。
[97] 一般に、元の状態では構文的に正しくない複数の同名のヘッダーの値を連結することで、 構文的に正しくなり、連結したかどうかによって異なる処理がなされてしまう場合があり得ます。 受信者によって違った解釈をされ得るものは、セキュリティーホールとして攻撃に使われる虞があります。
[440] CGI ではヘッダーをメタ変数にする時に、同じ名前のヘッダーが複数あれば
, により連結することになっています。これはヘッダーの種類に関わらず適用されます。
[129]
DOM
の
Headers
オブジェクトの
get
メソッドは、
複数のヘッダーがあるとき
「, 」
(0x2C 0x20)
で連結して返すと定められています。
[40] RFC 7231 はヘッダーの値が1つかリストか、 リストでない場合に複数のヘッダーが指定された時どうする処理するべきかをヘッダーの仕様書が明記することを検討するよう求めています >>39。
[443] Vary: ヘッダーは構文が # を使って定義されていますが、
それとは別に * という値も認められていて、「欄値全体が #」
という条件を満たしませんから、複数指定できません。
[57] RFC 4236 は、 RFC 2616 では拡張ヘッダーは同名で複数含めることが認められていないとして、 OPES に未対応の HTTP 串は動作しないかもしれないと主張しています >>56。 RFC 2616 の何を根拠としているのかは不明ですし、 RFC 723x にはそのような制限はありません。
[98] WebSocket handshake で使われるヘッダーの一部は、 要求と応答のいずれであるかによって、 複数指定できるかどうかが異なります。
[445] ヘッダーを複数指定できるかどうかは、 >>444 の JSON データファイルの
multiple フラグで確認できます。
[435] 串は、通信連鎖の端点や資源の状態や選択された表現 (payload 以外) についての情報を提供するヘッダーについては、 特に認められている場合やプライバシーやセキュリティーのため必要な場合を除き、 変更するべきではありません >>434。
[45] HTTP の仕様上は >>435 のような限定的な要件しか示されていますが、 実用上、串は、ヘッダーの定義上求められている場合と変形のために必要な場合を除き、 ヘッダーを追加したり、削除したりするべきではないと思われます。
[2] CGI においては、要求メッセージに含まれるHTTPヘッダーは
HTTP_* メタ変数群によって鯖からCGIスクリプトに伝達されます。
[48] また応答メッセージに含まれるべきHTTPヘッダーは、
HTTPヘッダーとほぼ同等のCGIヘッダーによってCGIスクリプトから鯖に伝達されます。
HTTP_*、CGIヘッダー
[63] FCAST でも HTTPヘッダーがメタデータの記述方法として採用されています >>62。実装はこれに対応しなければなりません >>66。
[65] ただし UTF-8 で符号化されたテキストとされています >>62。
RFC 2616 では HTTPヘッダーは ISO-8859-1 とされていますが、
両者の関係は明確にはなっていません。
[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登録簿も同じ一覧表に掲載されているだけで、別のプロトコルとしての登録になっています。)
[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: のような独自拡張欄は載っていません。
怪しげな欄を抜き出してみると:
リンクがある wininet 系の関数で指定する値も含めているのかもしれませんが。
他にも Cookie: 欄が載っているとか。 WinIE からサーバーに Cookie 発行するんでしょうか?
: の前に WSP が入っていると扱えない UA があるので注意が必要です。[60] RFC 4229 は既存のHTTPヘッダーをIANA登録簿に登録されています。
登録時の「状態」は次のように決めているようです。
[61] I-D はいくつかだけ選ばれていて、登録対象になっていないものも多々ありますが、 どのように選択したのか不明です。また IETF と W3C 以外の標準化団体等のヘッダーや、広く用いられていても I-D などになっていないヘッダーはまったく含まれていません。
[8] URLRequestHeader - Adobe ActionScript® 3 (AS3 ) API Reference ( ( 版)) http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLRequestHeader.html
[9] IRC logs: freenode / #whatwg / 20140610 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140610
[10] Rework all things request headers · 35b2c8b · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/35b2c8b42797e1b2bc8e97f204aaf7c618599202
[11] Align with new Fetch header terminology and unsafe request flag · 6766628 · whatwg/xhr ( ( 版)) https://github.com/whatwg/xhr/commit/676662852dbb08836f3697f293484a78167938bf
[441] Illustrate how headers are (soon to be) divided in the platform · a6b39f5 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/a6b39f5bbc8163f5336c4c384d62480c5003bd5e
[442] Clarify header ideas a bit. Still not great. https://github.com/slightly... · 137ff3d · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/137ff3df74d0bb5cbc4aadbbdceb9169d30c3f36
[448] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3
[449] draft-aranda-dispatch-q4s-02 - The Quality for Service Protocol ( ( 版)) http://tools.ietf.org/html/draft-aranda-dispatch-q4s-02#section-4
[451] RFC 4037 - Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core ( ( 版)) https://tools.ietf.org/html/rfc4037#section-3.1
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.
[102] nextthing.org » Fun With HTTP Headers ( 版) http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers
[103] HTTP header representation in Fetch (Anne van Kesteren 著, 版) https://lists.w3.org/Archives/Public/www-archive/2016Jan/0006.html
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;
[105] Fix #189: expose headers as a basic map in Headers · whatwg/fetch@42464c8 ( 版) https://github.com/whatwg/fetch/commit/42464c8c3d2fd3437a19fc6afd2438a0fd42dde8
[106] 918764 – [XHR2] Wrong exception: "TypeError" is not "DOMException SyntaxError" ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=918764
[107] Editorial: extract header sorting and combining ( (annevk著, )) https://github.com/whatwg/fetch/commit/9ca86dd4bebb0d0d7093893d4f3fef9a7d85dfad
[108] Define get(All)ResponseHeader(s) in terms of Fetch ( (annevk著, )) https://github.com/whatwg/xhr/commit/ecce3904ace0dbe382a652ea1d8e29c7885fe8c4
The HTTP request headers to send as a single, complete string.
"state": {
"type": "HttpRequestState",
"value": "Accept: application/pdf"
}
[114] Web Annotation Vocabulary () https://w3c.github.io/web-annotation/vocab/wd/#h-httprequeststate
[115] Selectors and States () https://w3c.github.io/web-annotation/selector-note/#h-httprequeststate_def
[116] Sort and lowercase header names in getAllResponseHeaders() example (annevk著, ) https://github.com/whatwg/xhr/commit/76b482b68ed9c27e0cc65fd3a6e663999cfc25e4
[117] Editorial: make Request/Response's headers its own concept (jakearchibald著, ) https://github.com/whatwg/fetch/commit/07999e9e5911ca246de2f31aace16f8eca9003bd
[118] Editorial: Making headers their own property by jakearchibald · Pull Request #575 · whatwg/fetch () https://github.com/whatwg/fetch/pull/575
[119] 655389 - CRLF Injection and the parsing of HTTP headers () https://bugzilla.mozilla.org/show_bug.cgi?id=655389
[120] draft-nottingham-structured-headers-00 - Structured Headers for HTTP () https://tools.ietf.org/html/draft-nottingham-structured-headers-00
[121] ABNF for metric-value · Issue #12 · w3c/server-timing () https://github.com/w3c/server-timing/issues/12
[122] Review request for Server-Timing · Issue #188 · w3ctag/design-reviews () https://github.com/w3ctag/design-reviews/issues/188
[123] Fix Origin header and "no-cors" redirects behavior (annevk著, ) https://github.com/whatwg/fetch/commit/af45ce34d6943c2a31cfa1d306d6db3b24682634
[125] Specify identity encoding for range requests (jakearchibald著, ) https://github.com/whatwg/fetch/commit/2f3d04d3713f6cd0f89d491217175b55911927be
[34] Define parsing for X-Content-Type-Options: nosniff in detail (annevk著, ) https://github.com/whatwg/fetch/commit/32c7b1c76a43ea96b8663628b891b339553ae114
[49] mnot’s blog: Designing Headers for HTTP Compression () https://www.mnot.net/blog/2018/11/27/header_compression
[67] Define the Content-Type header parser (annevk著, ) https://github.com/whatwg/fetch/commit/0b2bc05b2550dcbefe1321ea3e8026702514a798
[126] Editorial: defining header name sorting (annevk著, ) https://github.com/whatwg/fetch/commit/b7de58c0fc898089894d577b0ee07a2d97cc6094
[128] Command-Line Interface — Streamlink 1.6.0 documentation (, ) https://streamlink.github.io/cli.html#cmdoption-http-header
[132] protocol-registries/http-fields: Registry for HTTP field names (headers and trailers) () https://github.com/protocol-registries/http-fields
[134] Deliver Custom Content With CloudFront | AWS News Blog (, ) https://aws-amazon-com.translate.goog/blogs/aws/enhanced-cloudfront-customization/?_x_tr_sl=en&_x_tr_tl=ja&_x_tr_hl=ja&_x_tr_pto=sc