[419] 411 (Length Required) は、 Content-Length: ヘッダーを要求に含める必要があることを示す状態符号です。

仕様書

意味

[417] 411 は、 Content-Length: なしの要求を鯖が拒んだことを示す状態符号です >>416。

文脈

[412] 鯖は、メッセージ本体が含まれているにも関わらず Content-Length: が含まれていなければ、 411 を返して構いません >>320。

[415] Transfer-Encoding: があると Content-Length: は無視されることになっていて、 411 を返す必要はないはずですが、明示的に禁止はされていないようです。 RFC 7230 には、 chunked であっても Content-Length: がないと 411 を返す実装がある >>413 旨が指摘されています。

[420] HTTP クライアントには Content-Length: なしで POST などの要求を送信するものがあり、また HTTP 仕様上もそれが認められています。一方で HTTP 鯖には Content-Length: が指定されていないと 411 を返すものがあり、 HTTP 仕様上もそれが認められています。

[421] 当然の帰結として、 Content-Length: ヘッダーを送信しないクライアントや 411 を送信する鯖は、相互運用性が低い、 好ましくない実装ということになります。 ただし Content-Length: なしで Transfer-Encoding: chunked を使うのは HTTP/1.1 では基本的な構文なので、どちらかといえば 411 を返す鯖が好ましくないということになります。

処理モデル

[418] クライアントは、要求メッセージのメッセージ本体の長さを Content-Length: ヘッダーに入れて要求を繰り返して構いません >>416。

歴史

[414] RFC 2068 & 2616 (HTTP/1.1) 10.4.12 411 Length Required

The server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.

サーバーは、 Content-Length が定義されていない要求を受け入れるのを拒否します。 クライアントは、要求メッセージ中の message-body の長さを含んだ妥当な Content-Length 頭欄を加えれば要求を繰り返しても構いません。

[1] Bitbucket API () https://developer.atlassian.com/bitbucket/api/2/reference/meta/uri-uuid

You can get a 411 Length Required response. If this happens, the API requires a Content-Length header but the client is not sending it.