[43] Content-Length:
ヘッダーは、
メッセージ本体の長さを表します。メッセージ本体が存在する HTTP/1
メッセージで用いられます。
[45] Content-Length:
ヘッダーは、
Transfer-Encoding:
ヘッダーのないメッセージにおいて
payload body のサイズを表すことができます >>44。
これは payload body を含むメッセージにおいてはメッセージの終端の位置を表すフレーム付け情報として必要なものであり、
payload body を含まないメッセージにおいては選択された表現のサイズを示すものです
>>44。
[39] 要求メッセージは通常メッセージ本体を持ちませんが、
Content-Length:
がある場合はメッセージ本体を持ちます >>38。
[90] たまに Content-Length:
ヘッダーは必須だと思っている人がいるようですが、
実際にはそうではありません。むしろ指定してはならない場面も少なくありません。
一方で、必要な場面や、実質的に指定しなければ困る場面もあって、複雑になっています。
[47] 送信者は、 Transfer-Encoding:
ヘッダーがあるメッセージに
Content-Length:
ヘッダーを含めてはなりません >>44。
両方がある時は、 Transfer-Encoding:
が優先されます >>38 3.3.3.。送信者は転送前に Content-Length:
を削除しなければなりません >>38 3.3.3.。
[76] payload body を含む HTTP/2 の要求や応答は、
content-length
ヘッダーを含むことができます >>75。
その値は payload body を構成する DATA
フレームの payload 長の和と一致する必要があります。
[78] payload を持たないと定義されている HTTP/2 応答は、
content-length
ヘッダーを含むことができます >>75。
実際には DATA
フレームに内容が含まれていなくて構いません。
[313] 利用者エージェントは、メッセージ本体付きの要求を送る場合、
鯖が HTTP/1.1 に対応していると分かっている場合を除き、
Content-Length:
を送らなければなりません >>312。
[48] 利用者エージェントは、要求メソッドが payload body
の意味を定義している場合には、 Transfer-Encoding:
か Content-Length:
を送るべきです >>44。
要求メソッドが payload body の意味を定義しておらず、メッセージが
payload body を含んでいない場合には、
Content-Length:
を送るべきではありません
>>44。
[92] HTTP-network-or-cache fetch では、次のように決定されます >>91。
[306] 起源鯖は、 Transfer-Encoding:
を使用しない場合、事前に payload size が分かっているなら、
以降に示す場合を除き、 Content-Length:
ヘッダーを送信するべきです >>44。
[214] 鯖は、 OPTIONS
に対する応答に payload body を含まない場合、
Content-Length: 0
を生成しなければなりません >>206。
[50] 鯖は、 HEAD
要求に対する応答に
Content-Length:
ヘッダーを含めて構いませんが、
その場合 GET
だったなら返される応答で送られることになる
payload body のサイズを表すものでなければなりません >>44。
[51] 鯖は、条件付GETに対する 304
応答に
Content-Length:
ヘッダーを含めて構いませんが、
その場合 200
だったなら返される応答で送られることになる
payload body のサイズを表すものでなければなりません >>44。
[305] 鯖は、 1xx
応答、204
応答に Content-Length:
ヘッダーを含めてはなりません
>>44。
[311] 鯖は、 CONNECT
要求に対する 2xx
応答に Content-Length:
ヘッダーを含めてはなりません
>>44, >>314。 Content-Length:
ヘッダーがあっても、
無視しなければなりません >>38 3.3.3., >>314。
[307] 受信者は、大きな数値が指定される場合もありますから、 桁溢れによる構文解析エラーを防がなければなりません >>44。
[82] Chrome と Firefox はネットワークエラーとするようです。 IE はエラーにはしないようです (無視するかどうかは不明)。
[83] Chrome も Firefox も、 304
や
1xx
や
HEAD
への応答であっても、
不正な Content-Length:
をネットワークエラーとするようです。
[308] Content-Length:
ヘッダーが複数指定された場合やヘッダーの値がリストである場合で、
いずれも同じ十進数値の時は、このメッセージを非妥当であるとして拒絶するか、
Content-Length:
ヘッダー1つで数値1つに置き換えてから解釈したり、
転送したりするかのいずれかとしなければなりません >>44。
[309] Content-Length:
ヘッダーが無視されない場合で、
複数指定されていて値が異なる場合や、値が非妥当な場合は、
接続を閉じなければなりません >>312。
[80] Firefox は次のように決定しているようです。
[88] nginx は要求に複数の Content-Length
があるとき、
400
応答を返すようです。
Apache は Content-Length
を無視して接続が閉じられるのを待つようです。
[89] 要求の Content-Length
が不正な時、
nginx は 411
を返し、 Apache は 400
を返すようです。
[310] メッセージ本体の長さの決定方法は、 メッセージ本体の項を参照してください。
[52] メッセージ本体が指定された長さに満たない場合については、 不完全メッセージや HTTPS を参照してください。
[77] HTTP/2 メッセージの Content-Length:
ヘッダーの値が payload body を構成する DATA
フレームの payload 長の和と等しくなければ、
奇形です。 >>75
[84] 実際には Chrome は奇形とはせずに無視するようです。
Firefox は値が非負整数から始まりそれが実際の長さと一致する場合を除き、
接続エラー NO_ERROR
とします。
[71] FCAST の実装は、 Content-Length:
HTTPヘッダーに対応しなければなりません >>70。
CONTENT_LENGTH
(CGI)#✎[8] CGI のメタ変数 CONTENT_LENGTH
の値は、
要求に付随するメッセージ本体のサイズです >>20。
[4] 要求にメッセージ本体が存在している場合、その場合に限り、鯖は CONTENT_LENGTH
メタ変数を設定しなければなりません >>20。
[21] 値はメッセージ本体のサイズをオクテット単位の十進数で表したものです >>20。
[24] サイズは鯖が転送符号化や内容符号化を除去した後のメッセージ本体の長さでなければなりません >>20。
[22] メッセージ本体が付属していない場合は値は NULL (空文字列 or 未設定) です >>20。
CONTENT_LENGTH = "" | 1*digit
[27] HTTP によりますと HTTP 通信においては Content-Length:欄 は必須ではありません。それが無くても長さが特定出来る場合は 省略出来るのです。ですが、上記のように CGI script に渡される際には HTTP サーバーにより補われますので、 CGI script は安心して CONTENT_LENGTH の長さだけ標準入力を 読む、という処理が出来ます。
[28] HTTP の Content-Length:
欄の値と実際の内容長が一致しない場合のサーバーの動作に注意が必要です。 HTTP/1.1 だと多分問題になるのは与えられた内容長に達する前に接続がぶちぎられた場合ですか。そういう時適切な値に渡して CGI スクリプトに渡さないといけませんね。って普通そういう時は CGI スクリプトは実行しないかも。
[29] あるいは要求で chunked が使われてるけど Content-Length:
欄の指定もあって、両者も矛盾している時かな。こういう時に HTTP サーバーが CONTENT_LENGTH
をどうするべきかは規定がないと思いますが、実際の実体の長さをちゃんと返さないと駄目ですね。たぶんほとんどの CGI スクリプトは CONTENT_LENGTH
を妄信しますから。。。
[30] ほとんど (全て?) の実装では、メタ変数 HTTP_CONTENT_LENGTH
は提供されません。この CONTENT_LENGTH
で (実際にクライアントが指定した値を知りたいという奇特な場合を除いて) 不要ですから。
[31] 本体がないときには値 0
ではなく NULL
または空文字列になるのに注意が必要ですね。
[32] 注意しないといけないのは、 chunked 以外の転送符号化が使われているときです。 (>>29 が chunked の場合。 CGI には規定はないですが、 HTTP によれば Content-Length
が無視されます。) Content-Length
は転送符号化の結果の含めた長さですから、サーバーがスクリプトに転送符号化を解いた形でデータを渡す時には新しい値を設定しないといけません。 (サーバーがスクリプトに渡す前に転送符号化を解釈するべきかどうかは知らないんですが、ほとんどの CGI スクリプトの実装は転送符号化の存在がないと仮定してますよね。。。)
[33] >>32 今問題になってないのは、要求で転送符号化が使われることがまだそんなに (全然?) ないからに違いない。
CONTENT_LENGTH
を設定しなければならないという制約を考えると、起動前にメタ変数を確定させなければならない実装では、
本体の長さが確定するまでCGIスクリプトを起動できないことになります。
HTTP Content-Length:
欄が設定されていて転送符号化が使われていない場合であっても、
クライアントが途中で通信を切断する可能性があるので、最後まで読まないと値を確定できません。
(本当にそれでいいのでしょうか。実際の鯖の実装はそうなっていないように思います。)Content-Length:
欄 (電子メール)#✎[1] 2002-11-15 (金) 18:10 名無しさん: HTTP ではなく電子メイルや電子ニュースでも使われるのがたまに見られます。古い MIME の draft に書いてあったのではないかと思いますが、確認していません。
[2] 2002-11-15 (金) 18:11 名無しさん: MIME 的には Content-Disposition:欄の "size" パラメーターが後に用意されました。
[3] 2002-11-15 (金) 18:11 2: また電子ニュースでは伝統的に Lines:欄という似たものがあります。
length
異体属性#✎[57] 異体説明の length
異体属性は、
Content-Length:
ヘッダーに相当するものです >>56。
[58] 属性値は、1つ以上のASCII数字の列です >>56。
[59] 属性値は異体の長さを反映しなければなりません。 これには異体に埋め込まれたオブジェクトのサイズは含みません。 >>56
DAV:getcontentlength
特性 (WebDAV)#✎[61] DAV:getcontentlength
特性は、
accept header なしで GET
したら返されるであろう
Content-Length:
ヘッダーを含むものです >>60。
[64] Content-Length:
ヘッダーで OWS
が含まれる場合でも、特性値には含めるべきではありません >>62。
[65] WebDAV に従う資源で GET
要求に対して
Content-Length:
ヘッダーを含む応答を返すものは、
この特性を定義しなければなりません >>60。
Content-Length:
ヘッダー (FCAST)#✎[68] FCAST では Content-Length:
は内容符号化の適用前のオブジェクトの大きさを表します >>67, >>69。
[55] HTTP92 では「This should be part of the MIME header」 >>54
と言及されており、 Content-Type:
や
Content-Transfer-Encoding:
が MIME
の RFC を参照していることを見ても、 MIME
の改訂ないし拡張で純粋な HTTPヘッダーではないと考えられていたと思われます。
The Content-Length entity-header field indicates the size of the
{1945} Entity-Body{2068,2616} message-body, in decimal number of octets, sent to the recipient or, in the case of the HEAD method, the size of the{1945} Entity-Body{2068,2616} entity-body that would have been sent had the request been a GET.
Content-Length
実体頭欄は、受信者に送られる message-body
,
又は HEAD
method の場合には GET
での要求だったなら送られるであろう entity-body
の寸法をオクテット数の十進数表現で示します。
- Content-Length = "Content-Length" ":" 1*DIGIT
An example is
- Content-Length: 3495
Applications
{1945} should{2068} SHOULD use this field to indicate the size of the{1945} Entity-Body{2068,2616} message-body to be transferred, regardless of the media type of the entity.{1945} A valid Content-Length field value is required on all HTTP/1.0 request messages containing an entity body.{2068} It must be possible for the recipient to reliably determine the end of HTTP/1.1 requests containing an entity-body, e.g., because the request has a valid Content-Length field, uses Transfer-Encoding: chunked or a multipart body.
応用は、実体の媒体型に関わらず、転送する message-body
の寸法を示すのにこの欄を用いるべきです。 妥当な 受信者が Content-Length
欄値が、実体本体を含んでいる全ての HTTP/1.0 要求メッセージに必須です。entity-body
を含んだ HTTP/1.1 要求の終わりを確実に決定出来るように、例えば要求が妥当な Content-Length
欄を持つとか、 Transfer-Encoding: chunked
を使うとか、複数部分実体であるとかでなければなりません。
Any Content-Length greater than or equal to zero is a valid value. Section
{1945} 7.2.2{2068} 4.4 describes how to determine the length of a{1945} response entity body{2068} message-body if a Content-Length is not given.
零以上のどんな Content-Length も妥当な値です。4.4節は Content-Length がない時に message-body の長さがどう決定されるかを説明しています。
Note
: The {1945,2068}that the {2616} meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it{1945} should{2068} SHOULD be used whenever the{1945} entity{2068} message's length can be determined prior, unless this is prohibited by the rules in section 4.4 {2616}.
(要約: MIME の似たのとは違うのねん。)
The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):
メッセージの transfer-length は message 中にある message-body の長さです。 これは、 transfer-codings が適用された後のものです。 message-body がメッセージに含まれている場合、その本文の transfer-length は次のもののいずれか一つ (優先順) で決定されます。
1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.
message-body を含んでは「いけない」応答メッセージ (1xx, 204, 304 各応答と HEAD 要求の全ての応答) は常に頭欄の後の最初の 空行で終わります。メッセージに entity-header 欄があってもです。
2.If a Transfer-Encoding header field (section 14.41) is presentand has any value other than "identity",then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.
Transfer-Encoding
頭欄があって る場合、 identity
以外の値をとtransfer-length
は chunked
transfer-coding
の使用により定義されます。
但しメッセージが接続を閉じることにより終わる場合を除きます。
注 : 削除部分は errata (>>7) による。
3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
Content-Length 頭欄 (Content-Length:欄) がある場合、 OCTET での10進値が entity-length と transfer-length の両方を示します。 Content-Length 頭欄はこの2つの値が異なる (つまり Transfer-Encoding 頭欄がある) 時には送ってはなりません。 Transfer-Encoding 頭欄と Content-Length 欄の両方を含むメッセージを 受け取った場合は、後者は無視しないといけません。
4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.
メッセージが媒体型 "multipart/byteranges" を使用している場合、
かつ transfer-length が他で指定されていない時、この自己区切媒体型が
transfer-length
を定義します。
この媒体型は、受信者がこれを解析できると送信者が知っていない限り使ってはいけません。
HTTP/1.1 クライアントからの複数の byte-range 指定がある Range
頭がある要求は、クライアントが multipart/byteranges
応答を解析できることを暗示しています。
[7] 訳注: 原文欠落箇所は HTTP/1.1 Specification Errata http://world.std.com/~lawrence/http_errata.html#msg-len-chars http://purl.org/NET/http-errata#msg-len-chars]]
から補った。
A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section.
範囲頭は multipart/byteranges を理解しない HTTP/1.0 串が中継する かもしれません。この場合、サーバーはメッセージをこの節の 1,3,5 項のいずれかで定義された方法を使って区切らなければなりません。
5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
Messages MUST NOT include both a Content-Length header field and anon-identitytransfer-coding. If the message does include anon-identitytransfer-coding, the Content-Length MUST be ignored.
注 : 削除部分は errata (>>7) による。
When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.
This field contains the length of the content of the method (i.e. after the double CRLF following the last header). Unlike HTTP, it MUST be included in all messages that carry content beyond the header portion of the message. If it is missing, a default value of zero is assumed. It is interpreted according to [H14.14].
[5] この欄は、方式 の内容 (つまり、最後の頭の後の 2つの CRLF の後) の長さから成ります。 HTTP とは違って、メッセージの頭部分を超えた内容を伝える全てのメッセージはこれを含めなければなりません。 これが欠けていた場合は既定値の零とみなします。 これは [H14.14] により解釈します。
This metavariable is set to the size of the message-body entity attached to the request, if any, in decimal number of octets. If no data are attached, then this metavariable is either NULL or not defined. The syntax is the same as for the HTTP "Content-Length" header field (section 14.14, HTTP/1.1 specification [8]).
このメタ変数には、要求に添付されたメッセージ本体実体 があれば、その大きさを、10進のオクテット数で設定します。 データが添付されていない場合は、このメタ変数は NULL か未定義とします。 この構文は HTTP 「Content-Length」(内容長)頭領域 (HTTP/1.1 仕様書第14.14節) と同じです。
CONTENT_LENGTH = "" | 1*digit
Servers MUST provide this metavariable to scripts if the request was accompanied by a message-body entity.
サーバーは、要求にメッセージ本体実体がある場合、このメタ変数を スクリプトに提供しなければなりません。
object
要素 content-length
属性 (HTML)#✎[12] XHTML2 の object
要素には
content-length
属性が定義されていました。
[41] 参照されているオブジェクトのサイズを表すヒントとされていましたが、 どのように利用されるべきかは定義されていませんでした。
[13] 最初の作業原案では、属性の一覧には載っていましたが、肝心の定義が抜けていました。
[317] wget は、 CGIスクリプトに Content-Length:
を正しく扱えないものがあるとして、 Content-Length:
を無視する --ignore-length
オプションを用意しています。
HTTP
[9] RFC 3143 - Known HTTP Proxy/Caching Problems ( 版) http://tools.ietf.org/html/rfc3143#section-2.1.2
[10] セキュリティホール memo - 2005.07 http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/07.html#20050707_HRS
[11] RFC 3143 - Known HTTP Proxy/Caching Problems ( 版) http://tools.ietf.org/html/rfc3143#section-2.3.2
[35] RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks ( ( 版)) http://tools.ietf.org/html/rfc4463#section-5.4.9
[36] draft-wood-dtnrg-http-dtn-delivery-07 - Using HTTP for delivery in Delay/Disruption-Tolerant Networks ( ( 版)) http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-07#page-6
[37] RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2) ( ( 版)) http://tools.ietf.org/html/rfc6787#section-6.2.11
[315] XMLHttpRequest/send-entity-body-get-head* tests should not fail if Content-Length is 0 · Issue #980 · w3c/web-platform-tests ( ( 版)) https://github.com/w3c/web-platform-tests/issues/980
[316] chromium chromium/src/net/http/http_network_transaction.cc ( ( 版)) http://mxr.mozilla.org/chromium/source/src/net/http/http_network_transaction.cc#866
[318] RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer ( ( 版)) https://tools.ietf.org/html/rfc5547#page-30
[319] RFC Errata Report ( ( 版)) http://www.rfc-editor.org/errata_search.php?rfc=5547
We reject responses with negative Content-Length; Chrome accepts them and ignores the Content-Length (apparently).
[74] Define setting Content-Length and its quirks · whatwg/fetch@c103d09 ( 版) https://github.com/whatwg/fetch/commit/c103d0962dc4cb9e76c5425213fa8459509fa3d5
[85] No longer include Content-Length for HEAD requests (annevk著, ) https://github.com/whatwg/fetch/commit/674b4d3f9606b22993bc61e135f2739b668c85a1
[86] Issue 455939 - chromium - Stop sending Content-Length:0 header in all HEAD requests. - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=455939
[87] Preventing some CRLF header injection attacks · Issue #375 · whatwg/fetch () https://github.com/whatwg/fetch/issues/375
[96] video
要素で MP4 動画を再生させるとき、
動画の全体時間が表示されるかどうかについて、
Firefox では Content-Length:
の値が使われているようです。
指定されない場合には (本体全体を読み終わった後であっても) 全時間は表示されませんし、
現在時刻以後にシークもできません。
[97] Multiple Content-Length values that mismatch · Issue #59 · httpwg/http-core () https://github.com/httpwg/http-core/issues/59
[98] Parsing Content-Length by annevk · Pull Request #10548 · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/pull/10548
[99] CORS: safelist Content-Length header (benjamingr著, ) https://github.com/whatwg/fetch/commit/3a896efe58c45ba2073c2f8370a1b5e41c4f49aa
[100] Expose Content-Length header in CORS requests · Issue #622 · whatwg/fetch () https://github.com/whatwg/fetch/issues/622
[101] Safelist Content-Length header by benjamingr · Pull Request #626 · whatwg/fetch () https://github.com/whatwg/fetch/pull/626
[102] Allow Range header to be set by APIs (jakearchibald著, ) https://github.com/whatwg/fetch/commit/819d8c9d6617986a831ecd9cf21c34ba9589a890
For HTTP, Ignore the Content-Length header. This is particularly useful for servers running Apache 1.x, which will report incorrect Content-Length for files larger than 2 gigabytes.
[104] GNU Wget 1.20 Manual () https://www.gnu.org/software/wget/manual/wget.html#index-ignore-length
[106] ダウンロードの予想時間の見積もりってどうしたらいいんでしょうかね?
Content-Length
使えば良さそうと思ったんですけど、
chunked
が使われていると Content-Length
は信用できないし中間器に削除されちゃうことがあるのでしょう。
でも chunked
の長さは全体の長さとは限らない (そうでないことのほうが多い?) し。