[306] メッセージ本体は、メッセージのうち、 ヘッダーの後の空行の後にある部分です。
[311] メッセージ本体は、零個以上のオクテットの列です >>310。
[512] 初期の鯖はメッセージ本体の末尾が改行でないとメッセージ本体を読めないものがあったため、
古い HTTP/1.0 利用者エージェントは POST
要求の後に余分な CRLF を送ることがあります。 しかし
HTTP/1.1 利用者エージェントは要求の前後に余分な CRLF
をつけてはなりません。そのような対処が必要であれば、
CRLF もメッセージ本体に含めなければなりません。 >>511
[308] メッセージ本体は、HTTPメッセージのヘッダーの後の CRLF の後に置くことができます。場合によっては省略もできます。
[312] 要求メッセージでは、 Content-Length:
ヘッダーや
Transfer-Encoding:
ヘッダーがあるとき、
メッセージ本体が含まれることとなります >>310。
[528] クライアントは、 TRACE
要求においてメッセージ本体を送信してはなりません >>529。
[314] 応答メッセージでは、メッセージ本体が含まれるかどうかは要求メソッドと状態符号に依存して次のように決まります >>310。
205
は payload body の長さが0でなければならないとされています。
これは 204
とは違って payload body が存在していますが、
そこにデータが含まれることは禁止されています。[307] HTTP/0.9 要求メッセージには、メッセージ本体を含めることができません。
[309] HTTP/0.9 応答メッセージは、その全体がメッセージ本体です。
[523] クライアントはメッセージ本体の送信中に接続を監視して、 鯖が受信を望まず接続を閉じようとしていることがわかれば、 すぐに転送をやめて接続を閉じるべきです >>524。
[321] HTTP/1.0/HTTP/1.1 メッセージ本体の長さは、次のようにして決定します >>320。
CONNECT
要求に対する 2xx
応答なら、メッセージ本体はなく、かわりにトンネルが始まります。Transfer-Encoding:
ヘッダーの最後の転送符号化が
chunked
なら、メッセージ本体の長さは
chunked
符号化により決まります。Transfer-Encoding:
ヘッダーの最後の転送符号化が
chunked
以外なら、Transfer-Encoding:
がなく、
Content-Length:
があるものの、
複数あって値が異なるか、値が非妥当な時は、回復不能な誤りであり、Transfer-Encoding:
がなく、
Content-Length:
があって妥当な値の時は、
その十進数がメッセージ本体のオクテット単位の長さです。[510] 長さの決定には Transfer-Encoding:
ヘッダーと
Content-Length:
ヘッダーが深く関わっています。
両者の解釈と適合性については、それぞれの項も参照してください。
[401] Transfer-Encoding:
と Content-Length:
の両方がある時は、 Transfer-Encoding:
が優先されます。 request smuggling や response splitting
の兆候かもしれませんから、誤りとして扱うべきです。 >>320
[508] Content-Length:
も転送符号化もないと、
ネットワークエラーで接続が中断されたのとメッセージ本体の末端まで来たのと区別がつきませんから、
どちらかの方法を使うべきです >>320。
鯖は、メッセージ本体が含まれているにも関わらず Content-Length:
が含まれていなければ、 411
を返して構いません >>320。
multipart/byteranges
なら Content-Length:
がなくても構文上の末尾で終わることになっていました
>>525 が、 RFC 7230/RFC 7231 でこの規定は削除されています。[8] 実際の長さが指定に満たない場合については、不完全メッセージや HTTPS を参照してください。
[20] 応答のメッセージ本体が Content-Length:
に満たずに接続が閉じられた場合、 Chrome はネットワークエラーとします。
Firefox で HTTP/1.1 応答だと XHR ではネットワークエラー
(なぜかヘッダーは空にならず指定されたものにアクセスできます。)、
navigate では何も起こりません。 Firefox で HTTP/1.0
応答や IE では接続が閉じられるまでの部分を通常通り扱います。
[19] HTTP/1.0 応答を返してただちに接続を閉じた場合、
Content-Length:
よりも多くのデータをpayload bodyの続きで送信すると、
Firefox はその部分も payload body として扱います。
HTTP/1.1 応答の場合 (Connection: close
ありで閉じる場合も含む。) は
Content-Length:
分だけを payload body とします。
Chrome や IE は、 HTTP/1.0 でも Content-Length:
分だけを payload body とし、あとは捨てます。
[21] Chrome と Firefox は、 205
も 204
や 304
や HEAD
への応答と同じように、
常にメッセージ本体が存在しないものとして扱います。
Content-Length:
があっても無視されます。
[22] ただし Firefox は HTTP/1.0 では接続が閉じられるまでのすべてをメッセージ本体として扱います。
[23] IE は 304
や 205
や HEAD
への応答であっても、
Content-Length:
があればそちらを優先します
(HEAD
への応答かつ HTTP/1.1 の場合を除きます)。
304
や HEAD
への応答で
Content-Length:
がなく HTTP/1.1 なら、
接続が閉じられるまでがメッセージ本体となります。
[45] curl は、 HEAD
への応答であっても、
Content-Length:
があればそちらを優先します。
(HTTP/1.1 であってもです。)
[24] なお HTTP/0.9 応答の場合、 HEAD
要求の場合も含め、接続を閉じるまですべてがメッセージ本体として処理されます。
[25] IE は、 HTTP/1.0 または HTTP/1.1
の持続的接続で Content-Length:
により示されたメッセージ本体の終了後に更にデータを受け取った場合
(それが次の要求の送信よりも前の場合) には、
TCP RST
を送信するようです。
[26] Chrome と Firefox はその場合、受け取ったデータは捨てて、 送信後に受信したデータのみを応答の一部と解釈します。
[46] SSTP の SSTP_DUPLEX_POST
メソッドは、
CONNECT
メソッドのように機能するものです。要求[も応答も
Content-Length: 18446744073709551615
と指定することになっていて、実際の長さではなく、以後 SSTP に基づき処理されることとなります。
[533] メッセージ本体の長さには、仕様上の上限はありません。
multipart/x-mixed-replace
や Comet、
EventSource
のように、無限の長さのメッセージ本体が送受信されることもあります。
[534] 鯖は、要求メッセージのメッセージ本体が長すぎる場合、
413
応答を返すことができます。また、
HTTP接続を閉じることができます。
413
応答を送受信した場合であっても、
メッセージ本体の長さの決定方法は変化しません。従って、
接続をそのまま使い続けるためには、
クライアントはメッセージ本体を送り続けなければなりませんし、
鯖は (適宜無視しつつ) メッセージ本体を読み続けなければなりません。[41] CGI や PSGI では、サーバーからアプリケーションに
CONTENT_LENGTH
を引き渡さなければなりません。
つまり長さが確定しないことにはアプリケーションを起動できません。
CGI や PSGI では要求本体が途中で途切れたことをサーバーからアプリケーションに通知する手段はありませんから、
サーバーは要求本体をすべて受信し終わるまで待ってからアプリケーションを起動するしかありません。
[513] メッセージ本体は、 payload body そのものか、 payload body に転送符号化を適用したものです。
[509] 利用者エージェントは、最後の要求に対する最後の応答をすべて受信して、 尚もデータが残っているなら、これを捨てても構いませんし、 前の応答の本体の一部であるか判定しようとしても構いません。 しかしクライアントは、この余分なデータを別の応答として処理したり、 キャッシュしたり、転送したりしてはなりません。 >>320
[517] 串は、 no-transform
キャッシュ指令が指定されていれば、
payload を変形してはなりません。指定されていなければ、
変形して構いません。 >>515
[518] 変形が行われた場合、値 214
の Warning:
ヘッダーを (まだなければ) 追加しなければなりません。 >>515
[14] メッセージ本体の転送符号化適用前の状態が、 payload body です >>310。
[15] payload や payload body という用語は RFC 723x 世代から頻出するようになりましたが、 明確な定義はありません。 payload body は、 payload を構成する本体データ (メタデータでないもの) を表しているようです。
[17] RFC 7540 は RFC 7230 3.3 >>310 に「payload body」 の定義があると述べています >>16。しかし、確かに payload body に関する記述はありますが、「payload body は○○である」とはどこにも書かれていません。
[33] HTTP/2 では payload body は0個以上の DATA
フレームとして表されます。 (メッセージ本体の chunked
符号化に相当します。)
data:
URL#✎[49] data:
URL構造体は、
本体を持ち、
その値はバイト列です >>48。
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-coding has been applied, as indicated by the Transfer-Encoding header field (section
14.4014.41).
HTTP メッセージの message-body
は (あれば)
その要求または応答に関連付けられた entity-body
を伝達するのに使います。 message-body
は、
Transfer-Encoding
頭欄で示されたとおりの
transfer-coding
(転送符号化) を適用した時だけ
entity-body
と違います。
- message-body = entity-body | <entity-body encoded as per Transfer-Encoding
Transfer-Encoding
により符号化したentity-body
>
Transfer-Encoding MUST be used to indicate any transfer-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
canMAY be added or removed by any application along the request/response chain. (However, section 3.6 places restrictions on when certain transfer-codings may be used.)
応用がメッセージの安全で適切な転送のために適用した transfer-coding
を示すために Transfer-Encoding
を使用しなければなりません。
Transfer-Encoding
はメッセージの特性であって、
実体の特性ではなく、従って要求・応答鎖の任意の応用が追加したり削除したりして構いません。 (しかし、3.6節である transfer-coding
をいつ使っても良いかを制限しています。)
The rules for when a message-body is allowed in a message differ for requests and responses.
メッセージ中でいつ 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
MAYMUST NOT be included in a requestonly when the request method (section 5.1.1) allows an entity-bodyif the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. 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.
要求で message-body
があることは、
要求の message-headers
中に Content-Length
頭欄または Transfer-Encoding
頭欄を含めることで示します。
message-body
は、要求方式が 要求方式の仕様が要求で entity-body
を認めているときだけentity-body
を送ることを認めていなければ要求に含めて構いませんはなりません。サーバーは、任意の要求の message-body
を読み、転送するべきです。 entity-body
の意味を定義していない要求方式のときには、要求を処理するに当たって 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
mayMAY be of zero length.
応答メッセージでは、メッセージに message-body
を含めることができるかどうかは要求方式と応答状態符号の両方によって決まります。
HEAD
要求方式に対するすべての要求は、
entity-header
(実体頭) 欄が示されていて message-body
が含まれていると思えるように見えたとしても、 message-body
を含めてはなりません。すべての 1xx
(情報提供),
204
(無内容), 304
(無修正)
応答は message-body
を含んではなりません。
他のすべての応答は message-body
を含みます。
長さ零でも構いませんが。
The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the
Entity-Headerentity-header fields.
HTTP の要求または応答で送信される entity-body
は、
(ある場合) 実体頭欄で定義される書式と符号化を使います。
Entity-Body = *OCTET- entity-body = *OCTET
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.
実体本体は、要求方式がそれを呼び出すときのみ要求メッセージに含めます。
要求に実体本体があることは、 Content-Length
頭欄が要求メッセージ頭並びに含まれていることで通知されます。
実体本体を含んでいる HTTP/1.0 要求は妥当な Content-Length
頭欄を含んでいなければなりません。
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
maymight have been applied to ensure safe and proper transfer of the message.
entity-body
は4.3節で説明しているように message-body
が示されている時にのみメッセージに存在します。
entity-body
は、
メッセージの安全で適切な転送を確保するために適用されているかもしれない
Transfer-Encoding
を復号することで
message-body
から得ます。
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).
応答メッセージでは、メッセージに実体本体が含まれているかどうかは要求方式と応答符号の両方に依存します。
HEAD
要求方式に対するすべての応答は、
たとえ実体頭欄が存在して本体を含むように見えたとしても、本体を含んではいけません。
すべての 1xx
(情報提供), 204
(無内容),
304
(未修正) 応答は本体を含んではなりません。
他のすべての応答は実体本体を含むか、値が零 (0
)
で定義された Content-Length
頭欄を含んでいなければなりません。
注: この段落は RFC 2068・2616 では message-body
の節にありあます。
注: 注記なき変更点は 1945→2068 のもの。
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-coding
を適用した後の message-body
の長さです。メッセージに message-body
が含まれる時には、本体の転送長は次のいずれかにより決定します (優先順)。
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
要求に対する応答)
は、メッセージに現れる実体頭欄の如何にかかわらず、
常に頭欄並びの後の最初の空行で終端します。
2.
If a Transfer-Encoding header field (section14.4014.41) is present{2068} and indicates that the "chunked" transfer coding has been applied{2616:Errata で削除} and has any value other than "identity"]],]] then the transfer-length is defined by use of the "chunked"
encodingtransfer-coding (section 3.6) unless the message is terminated by closing the connection.
Transfer-Encoding
頭欄が示されており、いる時は、 転送長はメッセージが接続を閉じることによって終端される場合を除き、chunked
転送符号化が適用されていることが示されているidentity
以外の値であるchunked
transfer-coding
を使って定義します。3.
If a Content-Length header field (section14.1414.13) is present, its decimal value inbytesOCTETs representsthe length of the message-bodyboth 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
頭欄は、この2つの値が異なる (つまり、Transfer-Encoding
頭欄が示されている) 時には送ってはなりません。 メッセージにTransfer-Encoding
頭欄とContent-Length
頭欄の両方が示されているのを受信したときは、後者を無視しなければなりません。4.
If the message uses the media type "multipart/byteranges",which is self-delimitingand the transfer-length is not otherwise specified, thenthatthis self-delimiting media type defines the transfer-length. This media typeMUSTMUST NOT be used unless the sender knows that the recipient canparseparse it; the presence in a request of a Range header withmultiplemultiple byte-range specifiers from a 1.1 client implies that theclientclient can parse multipart/byteranges responses.メッセージが媒体型
multipart/byteranges
を使っていて、転送長が他で規定されないときは、 この自己区切媒体型が転送長を定義します。 この媒体型は、受信者がこれを解析できると送信者が知っているときを除いて使ってはなりません。 1.1 クライアントからの複数のバイト範囲指定子が要求の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
を理解しない 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.
HTTP/1.0 応用との互換性のため、
message-body
を含んだ HTTP/1.1 要求はサーバーが HTTP/1.1 適合と知っていない限り妥当なContent-Length
頭を含まなければなりません。 要求がmessage-body
を含んでいてContent-Length
が与えられていない場合、サーバーはメッセージの長さを決定できなければ400
(悪い要求) で、妥当なContent-Length
を受信することを主張したいなら411
(長さ必須) で応答するべきです。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.
実体を受信するすべての HTTP/1.1 応用は、
chunked
transfer-coding
を受け入れなければなりません。従って前もってメッセージの長さを決定できない時には、メッセージにこの機構を使うことができます。Messages MUST NOT include both a Content-Length header field and
{2068} the "chunked"{2616:Errataで削除} non-identitytransfer-coding. Ifboth are receivedthe message does include anon-identitytransfer-coding, the Content-Length MUST be ignored.メッセージは
Content-Length
頭欄とtransfer-coding
の両者を含んではなりません。メッセージがtransfer-coding
を含んでいる場合は、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.
message-body
が認められているところでメッセージにContent-Length
が与えられた時は、 その欄値はmessage-body
のOCTET
の数と正確に一致しなければなりません。 HTTP/1.1 利用者エージェントは、 不正な長さを受信して検出した時にはこれを利用者に通知しなければなりません。
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] messagebodyが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
(例えば 1xx
, 204
,
304
の応答) は、
常にheaderfieldの後の最初の空白行で終わります。
これはmessage中のentityheaderfield如何に関わりません。
(注意: 空行は 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] Content-Length
headerfieldがある場合、
そのバイト値がmessagebodyの長さとなります。
このheaderfieldが無い場合、
零の値であると仮定します。
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を終えることを示すのには使えません。 なぜなら、そうするとサーバーが応答を送り返すことも出来なくなってしまいます。)
訳注: 3つめの条件は HTTP に由来する物ですが、 全ての場合において2つめの条件で長さが決定するはずです。
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 の chunked
転送符号化に対応しておらず、
Content-Length
headerfieldの出現を必須としていることに注意して下さい。
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 転送符号化は不要となります。
何らかのentitybodyがある時には
Content-Length
を提示しなければならないとしても、
この規則に拠って長さが陽に与えられなかったとしても妥当な動作が確保できます。
{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.
メッセージに entity-body
が含まれる時には、本体の長さは2つの方法のいずれかにより決定します。
Content-Length
頭欄がある場合は、
そのバイト単位の値が 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 要求は妥当な Content-Length
頭欄を含めなければなりません。
要求が実体本体を含んでいて Content-Length
が指定されておらず、
サーバーが他の欄から長さを計算できないときは、サーバーは
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) を含んだ文書を送信する時に不正な Content-Length
を供給するものがあります。これは将来の版の HTTP
では通用しないであろうことを強調しておかねばなりません。
クライアントは適合サーバーから応答を受信しているのだと知らない限り、
Content-Length
値が正しいことに依存するべきではありません。
The entity-length of
an entity-bodymessage is the length of the message-bodyafterbefore any transfer-codings have beenremovedapplied. Section 4.4 defines how the transfer-length of a message-body is determined.
メッセージの entity-body
の実体長は transfer-coding
を適用する前の message-body
の長さです。
4.4節は message-body
の転送長をどう決定するかを定義しています。
[527] ProgressEvent's loaded/total now come from Fetch https://www.w3.org/Bugs... · b9f6bcf · whatwg/xhr ( ( 版)) <https://github.com/whatwg/xhr/commit/b9f6bcf9800963eb450b20cc96492a670fb96a99>
[536] Leave it up to those invoking fetch to throttle https://www.w3.org/Bugs/... · d7e357d · whatwg/fetch ( ( 版)) <https://github.com/whatwg/fetch/commit/d7e357d83380b50886832316c84ae125193b58b4>
[537] Put throttling back in now it's removed from Fetch. https://www.w3.org/B... · 0e3f85a · whatwg/xhr ( ( 版)) <https://github.com/whatwg/xhr/commit/0e3f85a60cd2938059d7594ba9242209aa13415d>
[13] Clear response body under certain conditions. Fixes #31 · whatwg/fetch@a9d4df4 ( 版) <https://github.com/whatwg/fetch/commit/a9d4df46c74fdd3e0505e228d950b873af1a055a>
Ultimately, this was a surprising and disappointing exercise; Content-Length is one of the most fundamental aspects of HTTP, and it’s one of the most important things to get right in order to ensure reliable operation of the protocol across myriad server, proxy, and client products. Alas, the “real world web” is polluted by buggy behavior and accommodating implementations, and hence it will likely be some time before products can increase their strictness without significant compatibility risk.
[28] Content-Length and Transfer-Encoding Validation in the IE10 Download Manager - IEInternals - Site Home - MSDN Blogs ( 版) <http://blogs.msdn.com/b/ieinternals/archive/2012/07/16/content-length-and-transfer-encoding-validation-in-ie10-download-manager-couldnt-be-downloaded-retry-cancel.aspx>
[29] daniel.haxx.se » Stricter HTTP 1.1 framing good bye ( 版) <http://daniel.haxx.se/blog/2014/10/26/stricter-http-1-1-framing-good-bye/>
ヘッダーのContentLengthと実際に受け取ったバイト数が違うというエラーです。
なおこのエラーはChromeでのみ起こるようです。
今回の解決方法はRuby on Railsのみですが、
rake tmp:clear
を実行します。
これによりキャッシュ等を削除することができます。
環境によってはサーバーの再起動が必要です。
[32] Fixing #118: add Response.prototype.body · whatwg/fetch@c51656b ( 版) <https://github.com/whatwg/fetch/commit/c51656bf3c35e4fd7f83c3574c041806417b0da6>
[18] Fix Response body IDL · whatwg/fetch@931fe45 ( 版) <https://github.com/whatwg/fetch/commit/931fe45a32d5dd956b35948c01fb4a0347327143>
[34] Fix #178: make bodies nullable · whatwg/fetch@27c6ab1 ( 版) <https://github.com/whatwg/fetch/commit/27c6ab1c42973fe2a6685f0a80e888de0b71fd69>
[35] nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita () <https://qiita.com/cubicdaiya/items/0678396f11982e537e2d>
maxPostSize
The maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value less than or equal to 0. If not specified, this attribute is set to 2097152 (2 megabytes).
post_max_size integer
Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize. Generally speaking, memory_limit should be larger than post_max_size. When an integer is used, the value is measured in bytes. Shorthand notation, as described in this FAQ, may also be used. If the size of post data is greater than post_max_size, the $_POST and $_FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $_GET variable to the script processing the data, i.e. <form action="edit.php?processed=1">, and then checking if $_GET['processed'] is set.
Note:
PHP allows shortcuts for byte values, including K (kilo), M (mega) and G (giga). PHP will do the conversions automatically if you use any of these. Be careful not to exceed the 32 bit signed integer limit (if you're using 32bit versions) as it will cause your script to fail.
Changelog for post_max_size
Version Description
5.3.4 post_max_size = 0 will not disable the limit when the content type is application/x-www-form-urlencoded or is not registered with PHP.
5.3.2 , 5.2.12 Allow unlimited post size by setting post_max_size to 0.
Name
post_max_size
Default
"8M"
テキストベースのボディパーサー ( text, json, xml, formUrlEncoded のような。) は全てのコンテンツを一旦メモリにロードする必要があるため、最大 content length が設定されています。
デフォルトでは content length は 100KB ですが、コード中で指定することもできます。
Syntax: client_max_body_size size;
Default:
client_max_body_size 1m;
Context: http, server, location
Sets the maximum allowed size of the client request body, specified in the “Content-Length” request header field. If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client. Please be aware that browsers cannot correctly display this error. Setting size to 0 disables checking of client request body size.
[42] Proposal: Support GET bodies · Issue #83 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/83>
[43] Fix Request's body handling (yutakahirano著, ) <https://github.com/whatwg/fetch/commit/55141d7644b4f8381814c82898a278796f7fd899>
[44] Fix Request's body handling (yutakahirano著, ) <https://github.com/whatwg/fetch/commit/55141d7644b4f8381814c82898a278796f7fd899>
[47] Clarify semantics of checking done, closed, etc. states of a null body stream · Issue #635 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/635>
[50] Allow used body replacement in Request constructor (harrishancock著, ) <https://github.com/whatwg/fetch/commit/5b7dae0fcc24cc8e025b216b80248d2619177ac4>