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 클라이언트 라이브러리는 문자열이나 버퍼를 보낼 때 이 값을 자동으로 계산합니다. 라이브러리가 해당 헤더를 제거하거나 값을 0으로 설정하고 있지 않은지 확인하세요.

요청이 청크 방식 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

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