413 요청 항목이 너무 큼 - TooBigBody

API 모니터링

API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.

1. <ph type="x-smartling-placeholder"></ph> 다음 계정으로 Apigee Edge UI에 로그인: 역할을 수행하는 것이 좋습니다.

2. 문제를 조사하려는 조직으로 전환합니다.

   
3. 분석 > API 모니터링 > 조사 페이지를 엽니다.
4. 오류가 관찰된 특정 기간을 선택합니다.
5. 프록시 필터를 선택하여 오류 코드의 범위를 좁힐 수 있습니다.
6. 시간을 기준으로 결함 코드를 표시합니다.

7. 결함 코드 protocol.http.TooBigBody가 있는 셀을 선택합니다. Status Code: 413

   

8. 결함 코드 protocol.http.TooBigBody에 대한 정보는 다음과 같이 표시됩니다. 다음과 같습니다.

   
9. 로그 보기를 클릭하고 실패한 요청의 행을 펼칩니다. 그런 다음 로그 창에서 아래에 표시된 세부정보를 확인합니다.

   비압축

   시나리오 #1: 비압축 형식으로 전송된 요청 페이로드

   

   로그 창에서 다음 세부정보를 확인합니다.

   • 상태 코드: 413
   • 오류 소스: proxy
   • 오류 코드: protocol.http.TooBigBody.
   • 요청 길이(바이트): 15360440 (~15MB)

   결함 소스의 값이 proxy이면 결함 코드입니다. 값은 protocol.http.TooBigBody이며 요청 길이가 포함됩니다. 10MB를 초과하는 경우 클라이언트의 HTTP 요청에 요청 페이로드 크기가 Apigee에서 허용되는 한도보다 큽니다.

   압축

   시나리오 #2: 압축된 형식으로 전송된 요청 페이로드

   

   로그 창에서 다음 세부정보를 확인합니다.

   • 상태 코드: 413
   • 오류 소스: proxy
   • 오류 코드: protocol.http.TooBigBody.
   • 요청 길이(바이트): 15264 (~15KB)

   결함 소스의 값이 proxy이면 결함 코드입니다. 값이 protocol.http.TooBigBody이고 요청 길이가 10MB 미만이면 클라이언트의 HTTP 요청에 요청 페이로드 크기가 압축된 형식의 허용된 제한보다 작아야 하지만 페이로드 크기가 Apigee로 압축하지 않을 때 허용되는 한도보다 큽니다.

Trace

Trace 도구를 사용하여 오류를 진단하는 방법은 다음과 같습니다.

1. 추적 세션을 사용 설정하고 다음 중 하나를 수행합니다. <ph type="x-smartling-placeholder">
   </ph>
   • 413 Request Entity Too Large 오류가 발생할 때까지 기다리거나
   • 문제를 재현할 수 있다면 API를 호출하고 재현합니다. 오류 413 Request Entity Too Large개

2. Show all Flow Infos(모든 흐름 정보 표시)가 사용 설정되어 있는지 확인합니다.

   
3. 실패한 요청 중 하나를 선택하고 trace를 검토합니다.
4. Request Received from Client 단계로 이동합니다.

   비압축

   시나리오 #1: 비압축 형식으로 전송된 요청 페이로드

   

   다음 정보를 참고하세요.

   • Content-Encoding: 없음
   • 콘텐츠 길이: 15360204

   압축

   시나리오 #2: 압축된 형식으로 전송된 요청 페이로드

   

   다음 정보를 참고하세요.

   • 콘텐츠 인코딩: gzip
   • 콘텐츠 길이: 14969
   • 콘텐츠 유형: application/x-gzip
5. 추적의 여러 단계를 살펴보고 오류가 발생한 위치를 찾습니다.

6. 오류는 일반적으로 Request Received from Client 단계의 다음 안내를 따르세요.

   
7. 트레이스에서 오류 값을 확인합니다. 위의 샘플 trace는 다음을 보여줍니다. <ph type="x-smartling-placeholder">
   </ph>
   • 오류: Body buffer overflow
   • error.class: com.apigee.errors.http.user.RequestTooLarge

8. Response Sent to Client로 이동하여 trace를 반환합니다. 아래의 샘플 트레이스는 다음과 같습니다.

   • 오류: 413 Request Entity Too Large
   • 오류 콘텐츠: <ph type="x-smartling-placeholder">{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}</ph>
   
9. 트레이스의 AX (애널리틱스 데이터 기록됨) 단계로 이동하여 클릭합니다.

10. 단계 세부정보 섹션에서 변수 읽기까지 아래로 스크롤합니다.

    
11. 다음을 나타내는 client.received.content.length 변수의 값을 결정합니다. <ph type="x-smartling-placeholder">
    </ph>
    • 요청 페이로드가 압축되지 않은 형식으로 전송될 때의 실제 크기이며
    • 페이로드가 다음에 해당하는 경우 Apigee에서 압축 해제 시 요청 페이로드의 크기입니다. 압축된 형식으로 전송됩니다 허용되는 한도 (10MB)로 제한됩니다.
    를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

    비압축

    시나리오 #1: 비압축 형식의 페이로드 요청

    

    client.received.content.length 변수: 15360204

    압축

    시나리오 #2: 압축된 형식의 요청 페이로드

    

    client.received.content.length 변수: 10489856

12. 다음 표에서는 다음 조건에서 Apigee가 413 오류를 반환하는 이유를 설명합니다. client.received.content.length 변수 값에 기반한 두 가지 시나리오가 있습니다.

    시나리오	client.received.content.length 값	실패 이유
    비압축 형식의 요청 페이로드	약 15MB	크기 > 허용되는 한도는 10MB입니다.
    압축된 형식의 페이로드 요청	약 10MB	압축 해제 시 크기 제한을 초과했습니다. <ph type="x-smartling-placeholder">

NGINX

NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.

1. Private Cloud 사용자인 경우 NGINX 액세스 로그를 사용하여 HTTP 413 오류에 대한 주요 정보입니다.

2. NGINX 액세스 로그를 확인합니다.

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

   <ph type="x-smartling-placeholder">
3. 특정 기간 동안 413 오류가 있는지 검색하여 확인합니다( 이전에 발생한 적이 있는지) 또는 여전히 413
4. 일치하는 X-Apigee-fault-code 에 413 오류가 있는 경우 protocol.http.TooBigBody의 값을 사용하고 X-Apigee-fault-source.

   비압축

   시나리오 #1 : 비압축 형식의 요청 페이로드 크기

   

   NGINX 액세스 로그의 위 샘플 항목에는 X-Apigee-fault-code 및 X-Apigee-fault-code 에 대한 값이 다음과 같습니다.

   응답 헤더	값
   X-Apigee-fault-code	protocol.http.TooBigBody
   X-Apigee-fault-sourc	policy

   요청 길이: 15360440 (14.6MB > 허용 한도)를 참고하세요.

   압축

   시나리오 #2 : 압축된 형식의 페이로드 크기 요청

   

   NGINX 액세스 로그의 위 샘플 항목에는 X-Apigee-fault-code 및 X-Apigee-fault-code

   응답 헤더	값
   X-Apigee-fault-code	protocol.http.TooBigBody
   X-Apigee-fault-source	policy

   요청 길이: 15264 (14.9K < 허용 한도)를 참고하세요.

   이 시나리오에서는 Apigee Edge가 413 요청 시간이 길어질 수 있으므로 요청 길이가 허용 한도보다 낮습니다. 압축된 형식으로 전송되었는데 페이로드의 크기가 Apigee Edge의 압축 해제 시 한도

크기 수정

옵션 #1 [권장]: 페이로드 크기가 허용되는 한도

</ph>
1. 특정 클라이언트가 허용된 것보다 큰 요청 / 페이로드 크기를 전송하는 이유를 분석합니다. 한도에 정의된 대로 한도를 포함합니다.

2. 바람직하지 않은 경우 요청 / 페이로드를 전송하도록 클라이언트 애플리케이션을 수정합니다. 허용되는 한도보다 작은 크기를 허용하는 것이 좋습니다.

   위에서 설명한 예에서는 더 작은 크기의 파일을 전달하여 문제를 해결할 수 있습니다. 아래와 같이 test5mbfile (크기 5MB) 페이로드를 가정해 보겠습니다.

   curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
   

3. 허용 한도보다 많은 요청/페이로드를 전송하려면 확인할 수 있습니다.

서명된 URL 패턴

옵션 2 [권장]: Apigee Java콜아웃 내에서 서명된 URL 패턴 사용

10MB보다 큰 페이로드의 경우 Apigee는 Apigee 자바 콜아웃 <ph type="x-smartling-placeholder"></ph> GitHub의 Edge 콜아웃: 서명된 URL 생성기 예

스트리밍

옵션 #3 : 스트리밍 사용

API 프록시가 대용량 요청 및/또는 응답을 처리해야 하는 경우, streaming입니다.

CwC

옵션 4 : CwC 속성을 사용하여 버퍼 한도 늘리기

이 옵션은 권장 옵션을 사용할 수 없는 경우에만 사용해야 합니다. 기본 크기가 증가하면 성능 문제가 될 수 있습니다.

Apigee는 CwC 속성을 사용하면 요청 및 응답 페이로드 크기 제한. 자세한 내용은 <ph type="x-smartling-placeholder"></ph> 라우터 또는 메시지 프로세서의 메시지 크기 한도 설정