HTTP 413 Content Too Large: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 업로드 도구 또는 모니터링 검사에서 HTTP 413 Content Too Large를 받습니다.
• 대용량 파일, 폼, JSON 문서, multipart 요청 또는 기타 요청 본문을 제출할 때 오류가 발생합니다.
• 동일한 요청의 작은 버전은 성공하지만 큰 요청은 실패할 수 있습니다.
• 응답은 프록시, CDN, WAF, 웹 서버 또는 애플리케이션에서 생성될 수 있으며, 어느 계층에서 생성되었는지에 따라 헤더나 본문 텍스트가 다를 수 있습니다.
• 사이트의 나머지 부분은 계속 이용 가능하고, 관련 없는 URL이나 요청 유형도 계속 작동할 수 있습니다.
• 413은 HTTP 계층의 응답이므로 DNS 확인과 TLS가 정상이어도 발생할 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 요청이 업로드 또는 본문 크기 제한을 초과합니다. 애플리케이션이나 웹 서버가 최대 요청 본문, 파일, 폼 또는 multipart 크기를 적용할 수 있습니다.
2. 중간 구성 요소에 더 낮은 제한이 있습니다. reverse proxy, CDN, load balancer 또는 WAF가 origin 애플리케이션이 요청을 받기 전에 요청을 거부할 수 있습니다.
3. 요청이 더 엄격한 엔드포인트로 라우팅됩니다. URL, 메서드, virtual host 또는 환경에 따라 크기 정책이 다를 수 있습니다.
4. 구성 제한이 서로 일치하지 않습니다. 프록시는 허용하지만 애플리케이션이 거부할 수 있고, 반대로 애플리케이션은 허용하지만 프록시가 차단할 수도 있습니다.
5. 요청이 예상보다 의도치 않게 커졌습니다. multipart 오버헤드, 지나치게 큰 인코딩 필드, 첨부 파일 또는 중복 데이터가 포함된 클라이언트 재시도로 인해 본문 크기가 증가할 수 있습니다.
6. 엔드포인트가 의도적으로 큰 콘텐츠를 거부합니다. 일부 API나 업로드 경로에는 제품 또는 보안상의 제한이 있으므로, 의도된 정책을 확인하지 않고 제거해서는 안 됩니다.

해결 방법

방문자 및 API 사용자

1. 정확한 URL을 확인하고, 반복해서 새로 고침하지 말고 요청을 한 번 다시 시도하세요.
2. 파일을 업로드하는 경우 더 작은 파일을 사용하거나, 승인된 형식 또는 압축 방법으로 파일 크기를 줄여 보세요.
3. API 요청의 경우 실패한 페이로드를 최소 유효 페이로드와 비교하세요. 예상보다 큰 필드, 삽입된 데이터, 중복 콘텐츠 또는 잘못 구성된 multipart 요청이 있는지 확인하세요.
4. 요청이 의도한 메서드와 콘텐츠 유형을 사용하는지 확인하세요. 오류를 우회하기 위해 인증 또는 보안 제어를 제거하지 마세요.
5. 작은 요청은 작동하지만 필요한 요청이 작동하지 않는 경우 사이트 운영자에게 URL, 메서드, 대략적인 요청 크기, 타임스탬프, 응답 헤더 및 페이로드에 대한 정제된 설명을 보내세요. 비밀번호, 쿠키, 토큰 또는 API secret은 공유하지 마세요.

사이트 운영자 및 개발자

1. 실패한 요청을 수집합니다. URL, HTTP 메서드, 콘텐츠 유형, 대략적인 본문 크기, 상태, 응답 헤더와 요청이 프록시, CDN, load balancer 또는 WAF를 통과하는지 여부를 기록하세요. 인증 정보와 개인 데이터를 삭제하거나 마스킹하세요.
2. 크기를 비교하며 재현합니다. 최소 유효 요청과 점진적으로 더 큰 요청을 테스트하거나, 성공한 업로드와 실패한 업로드를 비교하세요. 이렇게 하면 구성을 성급하게 변경하지 않고 실질적인 제한을 파악할 수 있습니다.
3. 생성 계층을 식별합니다. 동일한 타임스탬프와 요청에 대해 응답 본문, 헤더, access log, 프록시 로그, WAF 이벤트 및 애플리케이션 로그를 비교하세요. 애플리케이션 로그에 요청이 없다면 upstream 구성 요소가 먼저 요청을 거부했을 수 있습니다.
4. 경로상의 제한을 비교합니다. 관련 요청 본문, 업로드, multipart, 프록시, CDN, WAF 및 애플리케이션 제한을 확인하세요. 실질적인 제한은 요청을 거부하는 첫 번째 구성 요소에 의해 결정됩니다.
5. 가장 범위가 좁은 수정 방법을 선택합니다. 요청을 허용해야 한다면 권한, 메모리, 스토리지, 타임아웃 및 보안 영향을 확인한 후 관련 경로나 구성 요소만 조정하세요. 제한이 의도된 것이라면 그대로 유지하고 클라이언트 워크플로를 변경하거나 지원되는 최대 크기를 문서화하세요.
6. 원래 요청 패턴을 다시 테스트합니다. 동일한 메서드, URL, 콘텐츠 유형 및 대표적인 페이로드 크기를 사용하세요. 허용된 요청이 애플리케이션에 도달하는지, 잘못 구성되었거나 명백히 지나치게 큰 요청이 의도한 대로 계속 처리되는지 확인하세요.
7. 인접 동작을 확인합니다. 더 작은 요청, 관련 없는 경로, 인증 동작 및 구성 변경의 영향을 받는 다른 프록시나 애플리케이션 계층을 테스트하세요. 변경 사항을 버전 관리하고 최종 제한과 변경 이유를 기록하세요.

예방 및 해결 확인 방법

• 각 업로드 또는 API 경로에서 지원되는 최대 요청, 파일 및 multipart 크기를 문서화하세요.
• 가능한 경우 애플리케이션, 웹 서버, 프록시, CDN 및 WAF 제한을 확인할 수 있도록 관리하고 버전 관리하세요.
• 릴리스 전에 비프로덕션 환경에서 경계 크기와 대표적인 대용량 요청을 테스트하세요.
• 경로, 메서드, 클라이언트 및 배포별로 413 응답을 모니터링하여 예상치 못한 증가와 의도된 제한을 구분하세요.
• 클라이언트가 전송 전에 파일과 페이로드 크기를 검증하고, 요청이 너무 큰 경우 명확한 대안을 제공하도록 하세요.
• secret이나 불필요한 개인 데이터를 기록하지 않으면서 어느 계층이 요청을 거부했는지 확인할 수 있을 만큼 정제된 프록시 및 애플리케이션 로그를 보존하세요.

자주 묻는 질문