[43] Content-Length: ヘッダーは、 メッセージ本体の長さを表します。メッセージ本体が存在する HTTP/1 メッセージHTTPメッセージで用いられます。

仕様書

意味

[45] Content-Length: ヘッダーは、 Transfer-Encoding: ヘッダーのないメッセージにおいて payload body のサイズを表すことができます >>44。 これは payload body を含むメッセージにおいてはメッセージの終端の位置を表すフレーム付け情報として必要なものであり、 payload body を含まないメッセージにおいては選択された表現のサイズを示すものです >>44。

[39] 要求メッセージは通常メッセージ本体を持ちませんが、 Content-Length: がある場合はメッセージ本体を持ちます >>38。

[40] 要求メソッドには依存しません。

構文

[46] 1桁以上のASCII数字です >>44。オクテット単位の十進数と解釈されます >>44。

[49] メッセージ本体が空の時は、 0 となります。

文脈

[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。

  1. [93] 要求の本体要求本体が null で、 要求のメソッド要求メソッドが POST か PUT なら、 0 とします。
  2. [94] 要求の本体要求本体が null 以外で、 要求の本体要求本体の source が null 以外なら、 バイト数とします。
  3. [95] どちらでもない場合、設定しません。
[105] Webブラウザーは fetch による要求で Transfer-Encoding を使わないので、この手順群でもそれを検査していません。

[306] 起源鯖は、 Transfer-Encoding: を使用しない場合、事前に payload size が分かっているなら、 以降に示す場合を除き、 Content-Length: ヘッダーを送信するべきです >>44。

[214] 鯖は、 OPTIONS に対する応答に payload body を含まない場合、 Content-Length: 0 を生成しなければなりません >>206。

[50] 鯖は、 HEAD 要求に対する応答に Content-Length: ヘッダーを含めて構いませんが、 その場合 GET だったなら返される応答で送られることになる payload body のサイズを表すものでなければなりません >>44。

[53] キャッシュにおける蓄積された応答の更新に使われます。 HEAD

[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。

[79] Chrome は次のように決定しているようです。

  1. Content-Length: ヘッダーすべての値を , で連結します。
  2. , (前後に任意個の空白) で分割してリストを得ます。
  3. リストに ASCII数字列のみで構成されるバイト列が1つも含まれていないなら、 無指定として扱います。
  4. それ以外なら、
    1. リストからバイト列としての重複を除去します。
    2. 複数項目のリストなら、ネットワークエラーとします。
    3. それ以外なら、唯一のリスト項目を十進整数として使います。

[80] Firefox は次のように決定しているようです。

  1. 複数あって、値が異なるなら、ネットワークエラーとしてここで停止します。
  2. 値の先頭が ASCII数字列なら、十進整数を得ます。
  3. それ以外なら、無指定として扱います。

[81] IE は次のように決定しているようです。

  1. 複数あるなら、最初のものを使います。
  2. 値の先頭が ASCII数字列なら、十進整数を得ます。
  3. それ以外の値なら、 0 が指定されたとします。

[88] nginx は要求に複数の Content-Length があるとき、 400 応答を返すようです。 Apache は Content-Length を無視して接続HTTP接続が閉じられるのを待つようです。

[89] 要求の Content-Length が不正な時、 nginx は 411 を返し、 Apache は 400 を返すようです。

[310] メッセージ本体の長さの決定方法は、 メッセージ本体の項を参照してください。

[52] メッセージ本体が指定された長さに満たない場合については、 不完全メッセージや HTTPS を参照してください。

[77] HTTP/2 メッセージの Content-Length: ヘッダーの値が payload body を構成する DATA フレームの payload 長の和と等しくなければ、 奇形です。 >>75 HTTPメッセージ

[84] 実際には Chrome は奇形とはせずに無視するようです。 Firefox は値が非負整数から始まりそれが実際の長さと一致する場合を除き、 接続エラー NO_ERROR とします。

[71] FCAST の実装は、 Content-Length: HTTPヘッダーに対応しなければなりません >>70。

メタ変数 CONTENT_LENGTH (CGI)

[8] CGI のメタ変数 CONTENT_LENGTH の値は、 要求に付随するメッセージ本体message-bodyのサイズです >>20。

仕様書

  • [20] RFC 3875 - The Common Gateway Interface (CGI) Version 1.1 ( 版) http://tools.ietf.org/html/rfc3875#section-4.1.2

値

[4] 要求にメッセージ本体が存在している場合、その場合に限り、鯖は CONTENT_LENGTH メタ変数を設定しなければなりません >>20。

[21] 値はメッセージ本体のサイズをオクテット単位の十進数で表したものです >>20。

[24] サイズは鯖が転送符号化や内容符号化を除去した後のメッセージ本体の長さでなければなりません >>20。

[25] 転送符号化だけでなく内容符号化も必要に応じて除去しなければならないのですね。 要求データ

[22] メッセージ本体が付属していない場合は値は NULL (空文字列 or 未設定) です >>20。

[23]

      CONTENT_LENGTH = "" | 1*digit
>>20

メモ

[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 今問題になってないのは、要求で転送符号化が使われることがまだそんなに (全然?) ないからに違いない。

[34] HTTP 鯖はメッセージ本体をCGIスクリプトに引き渡す準備が出来る前に CGIスクリプトを起動しても良いとされていますが、 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。

[63] この特性は算出特性で、保護特性です >>60。

[65] WebDAV に従う資源で GET 要求に対して Content-Length: ヘッダーを含む応答を返すものは、 この特性を定義しなければなりません >>60。

[66] COPY や MOVE の後は、 終点資源のサイズを表す値となります >>60。

Content-Length: ヘッダー (FCAST)

[68] FCAST では Content-Length: は内容符号化の適用前のオブジェクトの大きさを表します >>67, >>69。

FCAST は HTTPヘッダーを使っていますが、メッセージの構造は HTTP と大きく異なっており、 Content-Length: はフレーム付けには使いません。

[72] それ以外は HTTP と同じようです。

歴史

HTTP92

[55] HTTP92 では「This should be part of the MIME header」 >>54 と言及されており、 Content-Type: や Content-Transfer-Encoding: が MIME の RFC を参照していることを見ても、 MIME の改訂ないし拡張で純粋な HTTPヘッダーではないと考えられていたと思われます。

  • [54] Object Header lines in HTTP ( 版) http://www.w3.org/Protocols/HTTP/Object_Headers.html#content-length

RFC

[15] RFC 1945 (HTTP/1.0) 10.4; RFC 2068 14.14; RFC 2616 14.13 (HTTP/1.1) Content-Length

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 の似たのとは違うのねん。)

[16] RFC 2616 (HTTP/1.1) 4.4 Message Length
   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 present and 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 a
   non-identity transfer-coding. If the message does include a non-identity transfer-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.
[17] RTSP (RFC 2326) 12.14 Content-Length

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] この欄は、方式method の内容 (つまり、最後の頭の後の 2つの CRLF の後) の長さから成ります。 HTTP とは違って、メッセージの頭部分を超えた内容を伝える全てのメッセージはこれを含めなければなりません。 これが欠けていた場合は既定値の零とみなします。 これは [H14.14] により解釈します。

CGI

[26] 6.1.2. CONTENT_LENGTH (CGI/1.1 draft 03)

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] 最初の作業原案では、属性の一覧には載っていましたが、肝心の定義が抜けていました。

  • [18] - XHTML Object Module ( 版) http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-object.html#s_objectmodule

[14] 2つ目の作業原案で定義が追加されました。

  • [19] - XHTML Object Module ( 版) http://www.w3.org/TR/2002/WD-xhtml2-20021211/mod-object.html#adef_object_content-length

[42] XHTML2 全体が支持を集められず、この属性も利用されることはありませんでした。

実装

[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

[73] Necko/Differences - MozillaWiki ( 版) https://wiki.mozilla.org/Necko/Differences

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

[103] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--ignore-content-length

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 の長さは全体の長さとは限らない (そうでないことのほうが多い?) し。