876.txt

[306] [RUBYB[[[メッセージ本体]]]@en[message body]]は、[[メッセージ]]のうち、
[[ヘッダー]]の後の[[空行]]の後にある部分です。

* 仕様書

[REFS[
- [310] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.3>'''
-- [320] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.3.3>
-- [511] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.5>
- [515] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#page-50>
- [524] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-6.5>
- [1] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
([TIME[2009-09-12 07:37:40 +09:00]] 版)
<http://tools.ietf.org/html/rfc5621>
]REFS]

* 文脈

[308] [[メッセージ本体]]は、[[HTTPメッセージ]]の[[ヘッダー]]の後の [[CRLF]]
の後に置くことができます。場合によっては省略もできます。

[312] [[要求メッセージ]]では、 [CODE(HTTP)@en[[[Content-Length:]]]] [[ヘッダー]]や
[CODE(HTTP)@en[[[Transfer-Encoding:]]]] [[ヘッダー]]があるとき、
[[メッセージ本体]]が含まれることとなります [SRC[>>310]]。

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

[314] [[応答メッセージ]]では、[[メッセージ本体]]が含まれるかどうかは[[要求メソッド]]と[[状態符号]]に依存して次のように決まります
[SRC[>>310]]。
- [315] [CODE(HTTP)@en[[[HEAD]]]] [[要求]]に対する[[応答]]は、[[メッセージ本体]]を持ちません。
- [316] [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]に対する [CODE(HTTP)[[[2xx]]]]
[[応答]]は、[[メッセージ本体]]を持たず、かわりに[[トンネル]]モードに切り替えます。
- [317] [CODE(HTTP)[[[1xx]]]], [CODE(HTTP)[[[204]]]], [CODE(HTTP)[[[304]]]]
の[[応答]]は、[[メッセージ本体]]を持ちません。
- [318] それ以外の[[応答]]は、[[メッセージ本体]]を持ちます。

[307] [[HTTP/0.9]] [[要求メッセージ]]には、[[メッセージ本体]]を含めることができません。

[309] [[HTTP/0.9]] [[応答メッセージ]]は、その全体が[[メッセージ本体]]です。

[523] [[クライアント]]は[[メッセージ本体]]の送信中に[[接続]]を監視して、
[[鯖]]が受信を望まず[[接続]]を閉じようとしていることがわかれば、
すぐに転送をやめて[[接続]]を閉じる[['''べきです''']] [SRC[>>524]]。

* 構文

[311] [[メッセージ本体]]は、零個以上の[[オクテット]]の列です [SRC[>>310]]。

[FIG(railroad)[
= *
== [[オクテット]]
]FIG]

[512] 初期の[[鯖]]は[[メッセージ本体]]の末尾が[[改行]]でないと[[メッセージ本体]]を読めないものがあったため、
古い [[HTTP/1.0]] [[利用者エージェント]]は [CODE(HTTP)[[[POST]]]]
[[要求]]の後に余分な [[CRLF]] を送ることがあります。 しかし
[[HTTP/1.1]] [[利用者エージェント]]は[[要求]]の前後に余分な [[CRLF]]
をつけては[['''なりません''']]。そのような対処が必要であれば、
[[CRLF]] も[[メッセージ本体]]に含めなければ[['''なりません''']]。 [SRC[>>511]]

* 長さの決定

[321] [[メッセージ本体]]の長さは、次のようにして決定します [SRC[>>320]]。
[FIG[
= [322] 次の場合、[[メッセージ本体]]はありません。
=- [323] [CODE(HTTP)@en[[[HEAD]]]] [[要求]]に対する[[応答]]
=- [324] [CODE(HTTP)[[[1xx]]]] [[応答]]
=- [325] [CODE(HTTP)[[[204]]]] [[応答]]
=- [326] [CODE(HTTP)[[[304]]]] [[応答]]
= [327] [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]に対する [CODE(HTTP)[[[2xx]]]] 
[[応答]]なら、[[メッセージ本体]]はなく、かわりに[[トンネル]]が始まります。
= [328] [CODE(HTTP)@en[[[Transfer-Encoding:]]]] [[ヘッダー]]の最後の[[転送符号化]]が
[CODE(HTTP)@en[[[chunked]]]] なら、[[メッセージ本体]]の長さは
[CODE(HTTP)@en[[[chunked]]]] [[符号化]]により決まります。
= [329] [CODE(HTTP)@en[[[Transfer-Encoding:]]]] [[ヘッダー]]の最後の[[転送符号化]]が
[CODE(HTTP)@en[[[chunked]]]] 以外なら、
=- [330] [[応答メッセージ]]では、[[鯖]]が[[接続]]を閉じたところまでが[[メッセージ本体]]です。
=- [331] [[要求メッセージ]]では、[[メッセージ本体]]の長さを決定できないので、
[CODE(HTTP)[[[400]]]] [[応答]]を返して[[接続]]を閉じなければ[['''なりません''']]。
= [402] [CODE(HTTP)@en[[[Transfer-Encoding:]]]] がなく、
[CODE(HTTP)@en[[[Content-Length:]]]] があるものの、
複数あって値が異なるか、値が[[非妥当]]な時は、回復不能な誤りであり、
=- [403] [[鯖]]が[[要求メッセージ]]を受信した場合は [CODE(HTTP)[[[400]]]]
[[応答]]を返して[[接続]]を閉じなければ[['''なりません''']]。
=- [404] [[串]]が[[応答メッセージ]]を受信した場合は[[鯖]]への[[接続]]を閉じて、
[[応答]]は捨てて、 [CODE(HTTP)[[[502]]]] [[応答]]を[[クライアント]]に返さなければ[['''なりません''']]。
=- [503] [[利用者エージェント]]が[[応答メッセージ]]を受信した場合は[[鯖]]への[[接続]]を閉じて、
[[応答]]は捨てなければ[['''なりません''']]。
= [504] [CODE(HTTP)@en[[[Transfer-Encoding:]]]] がなく、
[CODE(HTTP)@en[[[Content-Length:]]]] があって[[妥当]]な値の時は、
その[[十進数]]が[[メッセージ本体]]の[[オクテット]]単位の長さです。
=- [505] この長さに至らずに[[接続]]が閉じられたり、[[タイムアウト]]したりした場合は、
[[メッセージ]]は不完全とみなし、[[接続]]は閉じなければ[['''なりません''']]。
= [506] それ以外で[[要求メッセージ]]なら、[[メッセージ本体]]の長さは0です。
= [507] それ以外なら、[[鯖]]が[[接続]]を閉じるまでが[[メッセージ本体]]です。
]FIG]

[510] 長さの決定には [CODE(HTTP)@en[[[Transfer-Encoding:]]]] [[ヘッダー]]と
[CODE(HTTP)@en[[[Content-Length:]]]] [[ヘッダー]]が深く関わっています。
両者の解釈と適合性については、それぞれの項も参照してください。

[401] [CODE(HTTP)@en[[[Transfer-Encoding:]]]] と [CODE(HTTP)@en[[[Content-Length:]]]]
の両方がある時は、 [CODE(HTTP)@en[[[Transfer-Encoding:]]]]
が優先されます。 [[request smuggling]] や [[response splitting]]
の兆候かもしれませんから、[[誤り]]として扱う[RUBYB[べき]@en[ought to]]です。 [SRC[>>320]]

[508] [CODE(HTTP)@en[[[Content-Length:]]]] も[[転送符号化]]もないと、
ネットワークエラーで[[接続]]が中断されたのと[[メッセージ本体]]の末端まで来たのと区別がつきませんから、
どちらかの方法を使う[['''べきです''']] [SRC[>>320]]。
[[鯖]]は、[[メッセージ本体]]が含まれているにも関わらず [CODE(HTTP)[[[Content-Length:]]]]
が含まれていなければ、 [CODE(HTTP)[[[411]]]] を返して構いません [SRC[>>320]]。

* 転送符号化

[513] [[メッセージ本体]]は、 [[payload body]] そのものか、 [[payload body]]
に[[転送符号化]]を適用したものです。

;; [514] [[転送符号化]]や [CODE(HTTP)@en[[[Transfer-Encoding:]]]] や
[CODE(HTTP)@en[[[chunked]]]] の項を参照してください。

[516] [[串]]は、[[転送符号化]]を適用したり、除去したりできます [SRC[>>515]]。

* 構文解析

[509] [[利用者エージェント]]は、最後の[[要求]]に対する最後の[[応答]]をすべて受信して、
尚もデータが残っているなら、これを捨てても構いませんし、
前の[[応答]]の本体の一部であるか判定しようとしても構いません。
しかし[[クライアント]]は、この余分なデータを別の[[応答]]として処理したり、
[[キャッシュ]]したり、[[転送]]したりしては[['''なりません''']]。 [SRC[>>320]]

* 変形

[517] [[串]]は、 [CODE(HTTP)@en[[[no-transform]]]] [[キャッシュ指令]]が指定されていれば、
[[payload]] を[[変形]]しては[['''なりません''']]。指定されていなければ、
[[変形]]して構いません。 [SRC[>>515]]

[518] [[変形]]が行われた場合、値 [CODE(HTTP)[[[214]]]] の [CODE(HTTP)@en[[[Warning:]]]] 
[[ヘッダー]]を (まだなければ) 追加しなければ[['''なりません''']]。 [SRC[>>515]]

[519] [CODE(HTTP)[[[200]]]] [[応答]]を[[変形]]した場合、[[状態符号]]を
[CODE(HTTP)[[[203]]]] に変更できます。 [SRC[>>515]]

* 歴史

[FIG[
[FIGCAPTION[
[305] RFC 2068・2616 (HTTP/1.1) 4.3 Message Body
]FIGCAPTION]

> The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer[INS[-]]coding has been
applied, as indicated by the Transfer-Encoding header field (section [DEL[14.40]] [INS[14.41]]).

HTTP [[メッセージ]]の [CODE(ABNF)[message-body]] は (あれば)
その[[要求]]または[[応答]]に関連付けられた [CODE(ABNF)[[[entity-body]]]]
を伝達するのに使います。 [CODE(ABNF)[message-body]] は、
[CODE(HTTP)[[[Transfer-Encoding]]]] 頭欄で示されたとおりの
[CODE(ABNF)[transfer-coding]] ([[転送符号化]]) を適用した時だけ
[CODE(ABNF)[entity-body]] と違います。

>
- message-body = entity-body | <entity-body encoded as per Transfer-Encoding [INS[[CODE(HTTP)[Transfer-Encoding]] により符号化した [CODE(ABNF)[entity-body]]]]>

> Transfer-Encoding MUST be used to indicate any transfer[INS[-]]codings
applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the
entity, and thus [DEL[can]] [INS[MAY]] be added or removed by any application along the
request/response chain. [INS[(However, section 3.6 places restrictions on when certain transfer-codings may be used.)]]

[[応用]]がメッセージの安全で適切な転送のために適用した [CODE(ABNF)[transfer-coding]]
を示すために [CODE(HTTP)[Transfer-Encoding]] を使用しなければ'''なりません'''。
[CODE(HTTP)[Transfer-Encoding]] はメッセージの特性であって、
[[実体]]の特性ではなく、従って要求・応答鎖の任意の応用が追加したり削除したりして'''構いません'''。 [INS[(しかし、3.6節である [CODE(ABNF)[transfer-coding]] をいつ使っても良いかを制限しています。)]]

> The rules for when a message-body is allowed in a message differ for
requests and responses.

メッセージ中でいつ [CODE(ABNF)[message-body]] が認められるかの規則は要求と応答で異なります。

> The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body [DEL[MAY]] [INS[MUST NOT]] be included in a request [DEL[only when the request method (section 5.1.1) allows an entity-body]] [INS[if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests]]. [INS[A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request]].

要求で [CODE(ABNF)[message-body]] があることは、
要求の [CODE(ABNF)[message-headers]] 中に [CODE(HTTP)[[[Content-Length]]]]
頭欄または [CODE(ABNF)[[[Transfer-Encoding]]]] 頭欄を含めることで示します。
[CODE(ABNF)[message-body]] は、[DEL[[[要求方式]]が [CODE(ABNF)[entity-body]] を認めているときだけ]][INS[要求方式の仕様が要求で [CODE(ABNF)[entity-body]] を送ることを認めていなければ]]要求に含めて[DEL['''構いません''']][INS[は'''なりません''']]。[INS[サーバーは、任意の要求の [CODE(ABNF)[message-body]] を読み、転送する'''べきです'''。 [CODE(ABNF)[entity-body]] の意味を定義していない要求方式のときには、要求を処理するに当たって [CODE(ABNF)[message-body]] を無視する'''べきです'''。]]

> For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
status code (section 6.1.1). All responses to the HEAD request method
MUST NOT include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a
message-body, although it [DEL[may]] [INS[MAY]] be of zero length.

応答メッセージでは、メッセージに [CODE(ABNF)[message-body]]
を含めることができるかどうかは要求方式と応答[[状態符号]]の両方によって決まります。
[CODE(HTTP)[[[HEAD]]]] 要求方式に対するすべての要求は、
[CODE(ABNF)[entity-header]] (実体頭) 欄が示されていて [CODE(ABNF)[message-body]] 
が含まれていると思えるように見えたとしても、 [CODE(ABNF)[message-body]]
を含めては'''なりません'''。すべての [CODE(HTTP)[[[1xx]]]] (情報提供),
[CODE(HTTP)[[[204]]]] (無内容), [CODE(HTTP)[[[304]]]] (無修正)
応答は [CODE(ABNF)[message-body]] を含んでは'''なりません'''。
他のすべての応答は [CODE(ABNF)[message-body]] を含みます。
長さ零でも'''構いません'''が。
]FIG]

[FIG[
[FIGCAPTION[
[319] RFC 1945 (HTTP/1.0) ; RFC 2068・2616 (HTTP/1.1) 7.2 Entity Body
]FIGCAPTION]

> The entity[INS[-]]body (if any) sent with an HTTP request or response is in
a format and encoding defined by the [DEL[Entity-Header]] [INS[entity-header]] fields.

HTTP の要求または応答で送信される [CODE(ABNF)[entity-body]] は、
(ある場合) 実体頭欄で定義される書式と符号化を使います。

>
- [DEL[ Entity-Body    = *OCTET]]
- [INS[ entity-body    = *OCTET]]

[DEL[

> An entity body is included with a request message only when the
request method calls for one. The presence of an entity body in a
request is signaled by the inclusion of a Content-Length header field
in the request message headers. HTTP/1.0 requests containing an
entity body must include a valid Content-Length header field.

実体本体は、要求方式がそれを呼び出すときのみ要求メッセージに含めます。
要求に実体本体があることは、 [CODE(HTTP)[[[Content-Length]]]]
頭欄が要求メッセージ頭並びに含まれていることで通知されます。
実体本体を含んでいる HTTP/1.0 要求は妥当な [CODE(HTTP)[Content-Length]]
頭欄を含んでいなければなりません。
]DEL]

[INS[

> An entity-body is only present in a message when a message-body is
present, as described in section 4.3. The entity-body is obtained
from the message-body by decoding any Transfer-Encoding that [DEL[may]] [INS[might]] have
been applied to ensure safe and proper transfer of the message.

[CODE(ABNF)[entity-body]] は4.3節で説明しているように [CODE(ABNF)[[[message-body]]]]
が示されている時にのみメッセージに存在します。
[CODE(ABNF)[entity-body]] は、
メッセージの安全で適切な転送を確保するために適用されているかもしれない
[CODE(HTTP)[[[Transfer-Encoding]]]] を復号することで
[CODE(ABNF)[message-body]] から得ます。
]INS]

[DEL[

> For response messages, whether or not an entity body is included with
a message is dependent on both the request method and the response
code. All responses to the HEAD request method must not include a
body, even though the presence of entity header fields may lead one
to believe they do. All 1xx (informational), 204 (no content), and
304 (not modified) responses must not include a body. All other
responses must include an entity body or a Content-Length header
field defined with a value of zero (0).

応答メッセージでは、メッセージに実体本体が含まれているかどうかは要求方式と応答符号の両方に依存します。
[CODE(HTTP)[[[HEAD]]]] 要求方式に対するすべての応答は、
たとえ実体頭欄が存在して本体を含むように見えたとしても、本体を含んではいけません。
すべての [CODE(HTTP)[[[1xx]]]] (情報提供), [CODE(HTTP)[[[204]]]] (無内容),
[CODE(HTTP)[[[304]]]] (未修正) 応答は本体を含んではなりません。
他のすべての応答は実体本体を含むか、値が零 ([CODE(HTTP)[0]])
で定義された [CODE(HTTP)[Content-Length]] 頭欄を含んでいなければなりません。

[INS[

注: この段落は RFC 2068・2616 では [CODE(WikiPage)[[[message-body]]]]
の節にありあます。
]INS]
]DEL]

[INS[

注: 注記なき変更点は 1945→2068 のもの。
]INS]
]FIG]

[FIG[
[FIGCAPTION[
[520] RFC 2068・2616 (HTTP/1.1)  4.4 Message Length
]FIGCAPTION]

> [INS[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 [INS[transfer-]]length
of that body is determined by one of the following (in order of precedence):

メッセージの[DFN[転送長]]は、メッセージ中に現れる状態での、つまり 
[CODE(ABNF)[transfer-coding]] を適用した後の [CODE(ABNF)[[[message-body]]]]
の長さです。メッセージに [CODE(ABNF)[message-body]]
が含まれる時には、本体の転送長は次のいずれかにより決定します (優先順)。

> 1.[DEL[ ]]Any response message which [INS["]]MUST NOT[INS["]]
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.

[CODE(ABNF)[message-body]] を含めては「'''ならない''」
応答メッセージ ([CODE(HTTP)[[[1xx]]]], [CODE(HTTP)[[[204]]]],
[CODE(HTTP)[[[304]]]] 応答と [CODE(HTTP)[[[HEAD]]]] 要求に対する応答)
は、メッセージに現れる[[実体頭欄]]の如何にかかわらず、
常に頭欄並びの後の最初の空行で終端します。

> 2.[DEL[ ]]If a Transfer-Encoding header field (section [DEL[14.40]] [INS[14.41]]) is present [DEL[[DEL[[INS[{2068}]] and indicates that the "chunked" transfer coding has been applied]]
[INS[[INS[{2616:Errata で削除}]] and has any value other than "identity"]],]] 
then the [INS[transfer-]]length is defined by [INS[use of]] the [INS["]]chunked[INS["]] [DEL[encoding]] [INS[transfer-coding]] (section 3.6) [INS[unless the message is terminated by closing the connection]].

[CODE(HTTP)[[[Transfer-Encoding]]]] 頭欄が示されて[DEL[おり、[DEL[[CODE(HTTP)[[[chunked]]]] 転送符号化が適用されていることが示されている]][INS[[CODE(HTTP)[[[identity]]]] 以外の値である]]]][INS[いる]]時は、
転送長はメッセージが[[接続]]を閉じることによって終端される場合を除き、 
[CODE(HTTP)[chunked]] [CODE(ABNF)[transfer-coding]] を使って定義します。

> 3.[DEL[ ]]If a Content-Length header field (section [DEL[14.14]] [INS[14.13]]) is present, its [INS[decimal]] value in [DEL[bytes]] [INS[OCTETs]] represents [DEL[the length of the message-body]] [INS[both the entity-length and the transfer-length]]. [INS[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.]]

[CODE(HTTP)[[[Content-Length]]]] 頭欄が示されているときは、そのオクテット単位の十進値が[[実体長]]と転送長の両方を表します。
[CODE(HTTP)[Content-Length]] 頭欄は、この2つの値が異なる
(つまり、 [CODE(HTTP)[Transfer-Encoding]] 頭欄が示されている) 
時には送っては'''なりません'''。
メッセージに [CODE(HTTP)[Transfer-Encoding]] 頭欄と [CODE(HTTP)[Content-Length]]
頭欄の両方が示されているのを受信したときは、後者を無視しなければ'''なりません'''。

> 4.[DEL[ ]]If the message uses the media type "multipart/byteranges", [DEL[which is self-delimiting]] [INS[and the [INS[t]]ransfer-length is not otherwise specified]], then [DEL[that]] [INS[this self-[INS[d]]elimiting media type]]
defines the [INS[transfer-]]length. This media type [DEL[MUST]] [INS[[INS[M]]UST]] NOT
be used unless the sender knows that the recipient can [DEL[parse]] [INS[[INS[p]]arse]]
it; the presence in a request of a Range header with [DEL[multiple]] [INS[[INS[m]]ultiple]]
byte-range specifiers [INS[from a 1.1 client]] implies that the [DEL[client]] [INS[[INS[c]]lient]]
can parse multipart/byteranges responses.

メッセージが[[媒体型]] [CODE(MIME)[[[multipart/byteranges]]]] 
を使っていて、転送長が他で規定されないときは、
この自己区切媒体型が転送長を定義します。
この媒体型は、受信者がこれを解析できると送信者が知っているときを除いて使っては'''なりません'''。
1.1 クライアントからの複数のバイト範囲指定子が要求の [CODE(HTTP)[[[Range]]]] 頭に示されていればクライアントが
[CODE(MIME)[multipart/byteranges]] 応答を解析できることを暗示しています。

[INS[
> 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.

範囲頭は [CODE(MIME)[multipart/byteranges]] を理解しない 1.0
[[串]]により転送されるかもしれません。この場合、サーバーは
この節の1,3,5のいずれかで定義した方法を使ってメッセージを区切らなければ'''なりません'''。
]INS]

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

HTTP/1.0 応用との互換性のため、 [CODE(ABNF)[message-body]]
を含んだ HTTP/1.1 要求はサーバーが HTTP/1.1 適合と知っていない限り妥当な
[CODE(HTTP)[Content-Length]] 頭を含まなければ'''なりません'''。
要求が [CODE(ABNF)[message-body]] を含んでいて 
[CODE(HTTP)[Content-Length]] が与えられていない場合、サーバーはメッセージの長さを決定できなければ
[CODE(HTTP)[[[400]]]] (悪い要求) で、妥当な [CODE(HTTP)[Content-Length]]
を受信することを主張したいなら [CODE(HTTP)[[[411]]]]
(長さ必須) で応答する'''べきです'''。

> All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer[INS[-]]coding (section 3.6), thus allowing this mechanism
to be used for messages when the message length cannot be determined in advance.

実体を受信するすべての HTTP/1.1 応用は、
[CODE(HTTP)[chunked]] [CODE(ABNF)[transfer-coding]]
を受け入れなければ'''なりません'''。従って前もってメッセージの長さを決定できない時には、メッセージにこの機構を使うことができます。

> Messages MUST NOT include both a Content-Length header field 
and [DEL[[INS[{2068}]] the "chunked"]] [INS[[DEL[[INS[{2616:Errataで削除}]] non-identity]]]] transfer[INS[-]]coding. If [DEL[both are received]] [INS[the message does include a [DEL[non-identity]] transfer-coding]],
the Content-Length MUST be ignored.

メッセージは [CODE(HTTP)[Content-Length]] 頭欄と [CODE(ABNF)[transfer-coding]]
の両者を含んでは'''なりません'''。メッセージが
[CODE(ABNF)[transfer-coding]] を含んでいる場合は、
[CODE(HTTP)[Content-Length]] は無視しなければ'''なりません'''。

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

[CODE(ABNF)[message-body]] が認められているところでメッセージに
[CODE(HTTP)[Content-Length]] が与えられた時は、
その欄値は [CODE(ABNF)[message-body]] の [CODE(ABNF)[[[OCTET]]]]
の数と正確に一致しなければ'''なりません'''。 HTTP/1.1 [[利用者エージェント]]は、
不正な長さを受信して検出した時にはこれを[[利用者]]に通知しなければ'''なりません'''。
]FIG]

[FIG[
[FIGCAPTION[
[521] RFC 2326 (RTSP) 4.4 Message Length
]FIGCAPTION]

>When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence):

[2] __&&message&&____&&body&&__が__&&message&&__に含まれている時、
その__&&body&&__の長さは次により (この処理順で) 決定します。

>1.     Any response message which MUST NOT include a message body
(such as the 1xx, 204, and 304 responses) is always terminated
by the first empty line after the header fields, regardless of
the entity-header fields present in the message. (Note: An
empty line consists of only CRLF.)

[3] __&&message&&___&&body&&__を含んでは'''ならない'''応答__&&message&&__
(例えば [CODE(RTSP)[1[VAR[xx]]]], [CODE(RTSP)[[[204]]]],
[CODE(RTSP)[[[304]]]] の応答) は、
常に__&&header&&____&&field&&__の後の最初の空白行で終わります。
これは__&&message&&__中の__&&entity&&____&&header&&____&&field&&__如何に関わりません。
(注意: 空行は [CODE(char)[[[CRLF]]]] のみから成ります。)

>2.     If a Content-Length header field (section 12.14) is present,
its value in bytes represents the length of the message-body.
If this header field is not present, a value of zero is assumed.

[4] [CODE(RTSP)[Content-Length]] __&&header&&____&&field&&__がある場合、
そのバイト値が__&&message&&____&&body&&__の長さとなります。
この__&&header&&____&&field&&__が無い場合、
零の値であると仮定します。

>3.     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.)

[5] サーバーが接続を閉じることによります。
(接続を閉じることは要求__&&body&&__を終えることを示すのには使えません。
なぜなら、そうするとサーバーが応答を送り返すことも出来なくなってしまいます。)

[INS[
訳注: 3つめの条件は HTTP に由来する物ですが、
全ての場合において2つめの条件で長さが決定するはずです。
]INS]

>Note that RTSP does not (at present) support the HTTP/1.1 "chunked"
transfer coding(see [H3.6]) and requires the presence of the
Content-Length header field.

[6] [[RTSP]] は (現時点では) [[HTTP/1.1]] の [CODE[[[chunked]]]]
[[転送符号化]]に対応しておらず、
[CODE(RTSP)[Content-Length]] __&&header&&____&&field&&__の出現を必須としていることに注意して下さい。

>Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding
unnecessary. Even though Content-Length must be present if there is
any entity body, the rules ensure reasonable behavior even if the
length is not given explicitly.

[7] サーバーは返される__&&presentation&&__記述の適当な長さが与えられて、
この長さを常に決定することができる__&&should&&__。
たとえそれが動的に生成される物であるとしてもです。
そうすれば chunked 転送符号化は不要となります。
何らかの__&&entity&&____&&body&&__がある時には
[CODE(RTSP)[Content-Length]] を提示しなければならないとしても、
この規則に拠って長さが陽に与えられなかったとしても妥当な動作が確保できます。
]FIG]

[FIG[
[FIGCAPTION[
[522] RFC 1945 (HTTP/1.0)・RFC 2068 (HTTP/1.1) 7.2.2 Length; RFC 2616 (HTTP/1.1) 7.2.2 Entity Length
]FIGCAPTION]

[DEL[
>[INS[{1945}]] When an Entity-Body is included with a message, the length of that
body may be determined in one of two ways. If a Content-Length header
field is present, its value in bytes represents the length of the
Entity-Body. Otherwise, the body length is determined by the closing
of the connection by the server.

メッセージに [CODE(ABNF)[entity-body]]
が含まれる時には、本体の長さは2つの方法のいずれかにより決定します。
[CODE(HTTP)[Content-Length]] 頭欄がある場合は、
そのバイト単位の値が [CODE(ABNF)[entity-body]] の長さを表現します。
無い場合は、本体の長さはサーバーが接続を閉じることで決定します。

> Closing the connection cannot be used to indicate the end of a
request body, since it leaves no possibility for the server to send
back a response. Therefore, HTTP/1.0 requests containing an entity
body must include a valid Content-Length header field. If a request
contains an entity body and Content-Length is not specified, and the
server does not recognize or cannot calculate the length from other
fields, then the server should send a 400 (bad request) response.

クライアントが接続を閉じたらサーバーが応答を送り返すことができなくなってしまいますから、
要求本体の終わりを示すのに接続を閉じる方法は使えません。従って、実体本体を含む 
HTTP/1.0 要求は妥当な [CODE(HTTP)[Content-Length]] 頭欄を含めなければなりません。
要求が実体本体を含んでいて [CODE(HTTP)[Content-Length]] が指定されておらず、
サーバーが他の欄から長さを計算できないときは、サーバーは
[CODE(HTTP)[[[400]]]] (悪い要求) 応答を送るべきです。

> Note: Some older servers supply an invalid Content-Length when
sending a document that contains server-side includes dynamically
inserted into the data stream. It must be emphasized that this
will not be tolerated by future versions of HTTP. Unless the
client knows that it is receiving a response from a compliant
server, it should not depend on the Content-Length value being correct.

注意: 古いサーバーの中には、データ流に動的に挿入されるサーバー側取り込み
([[SSI]]) を含んだ文書を送信する時に不正な [CODE(HTTP)[Content-Length]]
を供給するものがあります。これは将来の版の HTTP
では通用しないであろうことを強調しておかねばなりません。
クライアントは適合サーバーから応答を受信しているのだと知らない限り、
[CODE(HTTP)[Content-Length]] 値が正しいことに依存するべきではありません。
]DEL]

[INS[
> The [INS[entity-]]length of [DEL[an entity-body]] [INS[message]] is the length of the message-body [DEL[after]] [INS[before]]
any transfer[INS[-]]codings have been [DEL[removed]] [INS[applied]]. Section 4.4 defines how the [INS[transfer-]]length of a message-body is determined.

メッセージの [CODE(ABNF)[entity-body]] の[DFN[実体長]]は [CODE(ABNF)[transfer-coding]]
を適用する前の [CODE(ABNF)[message-body]] の長さです。
4.4節は [CODE(ABNF)[message-body]] の転送長をどう決定するかを定義しています。
]INS]
]FIG]