411 Length Required
使い方
411 Length Required のエラーメッセージを受け取った場合、Content-Length ヘッダーを含めてリクエストを再送信しなければなりません。HTTP リクエストは一般にこのヘッダーを使ってメッセージボディの長さを指定しますが、常にそうとは限りません。たとえば、Transfer-Encoding ヘッダーフィールドが含まれ chunked に設定されている場合、Content-Length ヘッダーフィールドは必要ありません。
クライアントがデータのストリームを送信していてこのステータスが返された場合、データは代わりにサイズを指定したブロックで送信しなければなりません。
SEO への影響
Google のような検索エンジンは、411 Length Required のレスポンスステータスを持つ URL をインデックスしません。以前にインデックスされていた URL は検索結果から削除されます。このコードを返すページはクロールバジェットを消費しません。
例
クライアントがファイルを送信しようとしますが、メッセージボディの長さが指定されていないため、サーバーは 411 Length Required でリクエストを拒否します。
リクエスト
PUT /docs HTTP/1.1
Host: example.com
Content-Type: application/pdf
<PDF file included as message body>
レスポンス
HTTP/1.1 411 Length Required
対処方法
リクエストボディの正確なバイト数を伴う Content-Length ヘッダーを追加します。ほとんどの HTTP クライアントライブラリは、文字列やバッファを送信する際にこの値を自動的に計算します。ライブラリがこのヘッダーを取り除いたり値をゼロに設定したりしていないか検証します。
リクエストがチャンク形式の Transfer-Encoding を使っている場合、対象のサーバーはチャンク形式のボディを受け付けません。まずペイロード全体をバッファリングし、バイト長を計測して、代わりに Content-Length ヘッダーを伴ってボディを送信します。
プロキシやファイアウォールが転送中にヘッダーを取り除いたり変更したりすることがあります。クライアントが Content-Length を正しく送っているのにサーバーがなお 411 を返す場合は、サーバー側でリクエストを調べ、そのヘッダーが無傷で届いているか確認します。
curl では、-d フラグが Content-Length を自動的に設定します。curl で Transfer-Encoding: chunked を使う場合は -H “Transfer-Encoding: chunked” を使いますが、これはサーバーがチャンク転送をサポートしている場合に限ります。
サーバー側では、このステータスは厳格な設定や、チャンクエンコーディングをサポートしない古い HTTP/1.0 サーバーによって返されることがよくあります。サーバー管理者がこのポリシーを意図的に設定しており、対処は常にクライアント側で行います。
API テストツールにおける 411
Postman や curl のようなツールは、ほとんどのリクエストタイプで Content-Length ヘッダーを自動的に処理します。Postman での 411 エラーは通常、POST や PUT のリクエストでボディの種類を選択せずに空のボディを送信した場合に発生します。ボディの形式(raw、form-data、x-www-form-urlencoded)を選べば、Postman は Content-Length ヘッダーを正しく設定します。
コードリファレンス
.NET
HttpStatusCode.LengthRequired
Rust
http::StatusCode::LENGTH_REQUIRED
Rails
:length_required
Go
http.StatusLengthRequired
Symfony
Response::HTTP_LENGTH_REQUIRED
Python3.5+
http.HTTPStatus.LENGTH_REQUIRED
Java
java.net.HttpURLConnection.HTTP_LENGTH_REQUIRED
Apache HttpComponents Core
org.apache.hc.core5.http.HttpStatus.SC_LENGTH_REQUIRED
Angular
@angular/common/http/HttpStatusCode.LengthRequired