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}.

   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 の使用により定義されます。 但しメッセージが接続を閉じることにより終わる場合を除きます。

   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 応答を解析できることを暗示しています。

       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.

   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] この欄は、方式 (method) の内容 (つまり、最後の頭の後の 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.

サーバーは、要求にメッセージ本体実体がある場合、このメタ変数を スクリプトに提供しなければなりません。