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.40 14.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 can MAY 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 MAY MUST NOT be included in a request only when the request method (section 5.1.1) allows an entity-body if 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 may MAY 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-Header entity-header fields.

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

• Entity-Body = *OCTET
• entity-body = *OCTET

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 (section 14.40 14.41) is present {2068} and indicates that the "chunked" transfer coding has been applied

then the transfer-length is defined by use of the "chunked" encoding transfer-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 (section 14.14 14.13) is present, its decimal value in bytes OCTETs represents the length of the message-body 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 頭欄は、この2つの値が異なる (つまり、 Transfer-Encoding 頭欄が示されている) 時には送ってはなりません。 メッセージに Transfer-Encoding 頭欄と Content-Length 頭欄の両方が示されているのを受信したときは、後者を無視しなければなりません。

4. If the message uses the media type "multipart/byteranges", which is self-delimiting and the transfer-length is not otherwise specified, then that this self-delimiting media type defines the transfer-length. This media type MUST MUST NOT be used unless the sender knows that the recipient can parse parse it; the presence in a request of a Range header with multiple multiple byte-range specifiers from a 1.1 client implies that the client client 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-identity transfer-coding. If both are received the message does include a non-identity transfer-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を終えることを示すのには使えません。 なぜなら、そうするとサーバーが応答を送り返すことも出来なくなってしまいます。)

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 を提示しなければならないとしても、 この規則に拠って長さが陽に与えられなかったとしても妥当な動作が確保できます。

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.

ヘッダーのContentLengthと実際に受け取ったバイト数が違うというエラーです。

なおこのエラーはChromeでのみ起こるようです。

今回の解決方法はRuby on Railsのみですが、

rake tmp:clear

を実行します。

これによりキャッシュ等を削除することができます。

環境によってはサーバーの再起動が必要です。

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.