ヘッダー

ヘッダー (HTTP)

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

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

[19] 「header field」という用語は HTTP が影響を受けた RFC 822 などの電子メール仕様の用語に由来しますが、電子メールにおいても一般的にはヘッダーと呼ばれています。 「header field」全体の集合については、ヘッダー部 (ヘッダーリスト) を参照してください。

仕様書

意味

[15] ヘッダー (ヘッダー欄) は、ヘッダー名ヘッダー値で構成されます >>12

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

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

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

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

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

[76] ヘッダーは、欄名:欄値の順に指定します >>12

[75] 欄値の前後には空白 (OWS) を入れることができます >>12

  1. 字句
  2. :
  3. OWS
  4. 欄値
  5. OWS

[77] ヘッダーの直後には、必ず CRLF が必要です。

[78] ヘッダーは、ヘッダー部トレーラー部に任意の個数、指定できます。

構文解析

[85] HTTPの構文解析

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

[90] IEChrome では、 CR, LF, CRLF改行とみなされます。 Firefox では、 LF, CRLF改行とみなされます。

[101] ただしヘッダー部全体の末尾は、 LFCRLF が2組なければならないようです。 (IE では CR の連続 + LF も可。)

[95] (少なくても getAllResponseHeaders では) すべてのヘッダーの順序が保存されているようです。 ただし Chrome空白を含むヘッダー名のものはなぜか先頭に集められるようです。

[99] Chrome では、それ以外でも一部のヘッダーの順序が入れ替わることがありますが、 正確な条件は不明です。

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

[44] 歴史的に空白の扱いが異なる実装があったため、セキュリティー上の問題を引き起こしたことがありました >>43
[79] クライアントはどうしたら良いのでしょうか... 一貫性をもたせるなら、クライアントプロキシも、みなエラーとして扱うべき気がしますが...

[81] ChromeIEFirefox は (少なくても XHR では) : が含まれず空白で始まらない行や : で始まる行を無視します。

[86] Chrome は、 : の前に SPHTAB があれば、すべて削除します。 IE は、空白まで含めてヘッダー名とみなします。 Firefox は、そのヘッダー全体を無視します。

[80] ChromeIE では、 (XHR getAllResponseHeaders では) ヘッダー名大文字小文字が保存されています。 Firefox では、何らかの範囲で最初に見た大文字小文字の組み合わせに正規化されてしまうようです。

[92] ChromeIE では、ヘッダー名:空白を除くどんな文字でも良いようです。 (少なくても XHR からアクセスできます。) 途中であれば空白が含まれてもよく、正規化もされません。 Firefox では、 HTTP字句でなければならないようです。

[82] IEFirefoxChrome も、 開始行の次が継続行なら、黙って無視します。

[83] それ以外で (少なくても XHR では) 継続行がある場合、 Chrome改行とその後の SP/HTAB の列を1つの SP に置き換えます。 Firefox改行だけを除去します。 IEgetResponseHeader改行前までしか返しません。

[84] IE空白のみで構成される行があると、ヘッダー部の終わりの空行と誤認します。

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

[87] ChromeFirefox も、値の前後の SP/HTAB を除去します。これは継続行の改行の除去後に行われます。

[88] IE は値の後の SP/HTAB と、値の前の SP を除去します。

[89] Firefox は、 (少なくても XHR では) 空白の除去後に値が空になると、 そのヘッダー全体を無視します。 ChromeIE ではそんなことはありません。

[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 は通常通り処理を続けます。

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

[74] HTTP/2 には、 HTTP/1.1 と共通の通常の HTTPヘッダーと、 HTTP/1.1開始行に相当する疑似ヘッダーがあります。

[113] いずれのヘッダーも、ヘッダーリストを構成します。 ヘッダーリストは、 HPACK によりヘッダーブロックとして符号化し、 必要ならヘッダーブロック素片として分割し、 HEADERSPUSH_PROMISECONTINUATIONフレームpayload として送信されます >>73

文脈

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

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

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

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

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

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

処理

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

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

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

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

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

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

ヘッダーの種類

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

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

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

[47] しかし実際には大多数のヘッダーは登録されていません。 また HTTP 仕様上も登録されていないヘッダーの利用は禁止されていないようです。
[93] 登録簿は共通ですが、定義や登録自体は別々です。 また電子メールよりも HTTP に近い RTSPSIP のような HTTP 派生プロトコルは、独自の IANA登録簿を使っています。

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

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

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

ヘッダーの順序

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

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

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

[52] 別の名前のヘッダーの順序をが入れ替えることは仕様上禁止はされていないようですが、普通は入れ替えないものと思われます。
[53] ライブラリーフレームワークの類はヘッダーの一覧を順序を保持できないハッシュ連想配列のようなデータ構造に変換することがあります。 ですから送信者ヘッダーの順序に意味を持たせることができません。

同名ヘッダー

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

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

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

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

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

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

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

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

[32] 従って、 HTTP 仕様は , による連結を認めていますが、 現実には無条件で , によって連結することは Web互換ではありません。
[33] にも関わらず、プログラミング言語ライブラリーによっては連結した後の値しかプログラムに提供していないことがあります。

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

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

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

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

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

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

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

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

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

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

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

[50] キャッシュ項目

CGI

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

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

FCAST

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

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

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

歴史

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

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

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

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

[1] HTTP頭欄は4つに分類できます。

  1. 一般頭欄 (general-header fields)
  2. 要求頭欄 (request-header fields)
  3. 応答頭欄 (response-header fields)
  4. 実体頭欄 (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 発行するんでしょうか?

[60] RFC 4229 は既存のHTTPヘッダーIANA登録簿に登録されています。 登録時の「状態」は次のように決めているようです。

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

[450] JSONヘッダー値

[451] RFC 4037 - Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core ( ( 版)) https://tools.ietf.org/html/rfc4037#section-3.1

[72] HTML Standard ( 版) https://html.spec.whatwg.org/#concept-http-equivalent-headers

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

[104] Re: HTTP header representation in Fetch (Honza Bambas 著, 版) https://lists.w3.org/Archives/Public/www-archive/2016Jan/0013.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

[111] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/#h-request-header-state

The HTTP request headers to send as a single, complete string.

[112] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/#h-request-header-state

"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