[1] [[HTTPのABNF]] の [CODE(ABNF)[#]] は、[[リスト]]を表します。 [22] HTTP とか SIP とかだと、複数頭領域を読点区切りで単一頭領域にまとめることが 出来ます。 * 仕様書 [REFS[ - [2] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) ]REFS] * 構文 [3] [[ABNF]] において[[反復]]を表す [CODE[[[*]]]] のように、構文要素の直前に [DFN[[CODE[#]]]] を置くと、[[リスト]]を表します [SRC[>>2]]。 [4] [CODE[#]] の前後には、[[非負整数]]を指定でき、それぞれ最小と最大の一致数を表します [SRC[>>2]]。 省略された場合は、それぞれ [[0]] と [[∞]] を表します。 [FIG(railroad)[ = ? == [[ASCII数字]]1つ以上 = [CODE[#]] = ? == [[ASCII数字]]1つ以上 = 構文要素 ]FIG] * 意味 [5] [CODE[#]] の直後の構文要素が、指定されている最小数[[以上]]、最大数[[以下]]の回数繰り返すことを表します。 ただし、それぞれの間には [CODE[[[,]]]] が必要で、更にその前後には [[OWS]] が認められています [SRC[>>2]]。 [6] [[送信者]]は、 >>5 に[[一致]]するものを[[生成]]しなければ[['''なりません''']] [SRC[>>2]]。 [7] [[受信者]]は、それに加えて、空の要素があっても (合理的な範囲で) 無視しなければ[['''なりません''']] [SRC[>>2]]。すなわち、リストの最初や最後に [CODE[[[,]]]] があったり、 [CODE[[[,]]]] が連続したり (間に [[OWS]] のみしかなかったり) していても構いません。 その場合で、空でない要素の数が指定された範囲内になければなりません [SRC[>>2]]。 * 処理 [19] 同じ名前の複数の [[HTTPヘッダー]]が与えられた場合と、 それが連結された場合とで処理が変わってくる場合があります。 [20] [[Chrome]] の[[開発者ツール]]は [CODE[Server-Timing]] ヘッダーの内容を図示します。 複数のヘッダーで記述されていれば、そのどれかが構文エラーで表示されなくても、 他のヘッダーが正常ならそちらは表示されます。 ところが連結されているとすべて (エラー以降?) が表示されなくなったりします。 [21] 連結は思わぬところで発生します。 例えば[[サービスワーカー]]経由で[[文書環境]]に伝わるとき、 [[サービスワーカー]]内で[[ヘッダー]]を処理したタイミングで発生していたりします。 [[Chrome]] の[[開発者ツール]]でみていると、 [[サービスワーカー]]の [[fetch]] では図示されているのに大元の[[文書環境]]側の [[fetch]] では図示されていない、みたいな不思議現象として現れます。 * 文脈 [23] まとめられる頭領域: -[[Accept:領域]] ([[HTTP/1.1]]) -[[Accept-Charset:領域]] ([[HTTP/1.1]]) -[[Accept-Encoding:領域]] ([[HTTP/1.1]]) -[[Accept-Language:領域]] ([[HTTP/1.1]]) -[[Accept-Ranges:領域]] ([[HTTP/1.1]]) -[[Allow:領域]] ([[HTTP]], [[SIP]]) -[[Cache-Control:領域]] ([[HTTP/1.1]]) -[[Connection:領域]] ([[HTTP/1.1]]) -[[Contact:領域]] (m:) ([[SIP]]) -[[Content-Encoding:領域]] (e:) ([[HTTP/1.1]], [[SIP]]) -[[Content-Language:領域]] ([[HTTP/1.1]]) -[[Expect:領域]] ([[HTTP/1.1]]) -[[If-Match:領域]] ([[HTTP/1.1]]) -[[If-None-Match:領域]] ([[HTTP/1.1]]) -[[Keep-Alive:領域]] ([[HTTP/1.1]] [[RFC2068]]) -[[Link:領域]] ([[HTTP/1.1]] [[RFC2068]]) -[[Public:領域]] ([[HTTP/1.1]] [[RFC2068]]) -[[Pragma:領域]] ([[HTTP]]) -[[Proxy-Authenticate:領域]] ([[HTTP/1.1]]) -[[Record-Route:領域]] ([[SIP]]) -[[Require:領域]] ([[SIP]]) -[[Route:領域]] ([[SIP]]) -[[TE:領域]] ([[HTTP/1.1]]) -[[Trailer:領域]] ([[HTTP/1.1]]) -[[Transfer-Encoding:領域]] ([[HTTP/1.1]]) -[[Unsupported:領域]] ([[SIP]]) -[[Upgrade:領域]] ([[HTTP/1.1]]) -[[URI:領域]] ([[HTTP/1.1]] [[RFC2068]]) -[[Vary:領域]] ([[HTTP/1.1]]) -[[Via:領域]] (v:) ([[HTTP/1.1]], [[SIP]]) -[[Warning:領域]] ([[HTTP/1.1]], [[SIP]]) -[[WWW-Authenticate:領域]] ([[HTTP]]) [25] [[RTSP]] の [CODE[RTP-Info:]] では構文定義中、[[欄値]]の一部分のみに [CODE[#]] が使われています。仕様書の誤りが疑われます。 [SEE[ [[RTP-Info]] ]] * 関連 -[[メッセージの頭]] --[[RFC822と仲間達の頭領域名]] -[[HTTP]] [8] [[欄値]]が [CODE[#]] によって定義されているかどうかは、同名の[[ヘッダー]]が複数あってもよいかどうかを左右します。 詳しくは[[HTTPヘッダー]]の項を参照してください。 * 歴史 [FIG(quote)[ [24] [[RFC 2616]] HTTP/1.1 4.2 から抜粋 > Multiple message-header fields with the same field-name 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 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. ]FIG] [9] [CITE@en[Stop using "combined value"]] ([[annevk]]著, [TIME[2018-11-27 23:18:25 +09:00]]) [10] [CITE@en[Stop using "combined value" by annevk · Pull Request #229 · whatwg/xhr]] ([TIME[2019-06-01 11:08:18 +09:00]]) [11] [CITE@en[Fix: Appending a header to headers with "request-no-cors" guard by yutakahirano · Pull Request #840 · whatwg/fetch]] ([TIME[2019-06-01 11:08:37 +09:00]]) [12] [CITE@en[Remove "combined value" concept]] ([[yutakahirano]]著, [TIME[2018-11-30 01:58:47 +09:00]]) [13] [CITE@en[Remove "combined value" concept by yutakahirano · Pull Request #842 · whatwg/fetch]] ([TIME[2019-06-01 11:10:57 +09:00]]) [14] [CITE@en[Define the Content-Type header parser]] ([[annevk]]著, [TIME[2018-11-27 18:47:01 +09:00]]) [15] [CITE@en["Extract a MIME type" algorithm should pick the first entry? · Issue #529 · whatwg/fetch]] ([TIME[2019-06-19 15:03:04 +09:00]]) [16] [CITE@en[Define the Content-Type header parser by annevk · Pull Request #831 · whatwg/fetch]] ([TIME[2019-06-19 15:08:55 +09:00]]) [17] [CITE@en[Fix: Appending a header to headers with "request-no-cors" guard by yutakahirano · Pull Request #840 · whatwg/fetch]] ([TIME[2019-06-20 10:23:13 +09:00]]) [18] [CITE@en[CORS request-header Content-Type check should be on a combined value · Issue #748 · whatwg/fetch]] ([TIME[2019-06-21 12:40:36 +09:00]])