현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보
증상
클라이언트 애플리케이션은 API 호출에 대한 응답으로 오류 코드 protocol.http.TooBigBody 와 함께 HTTP 상태 코드 413 Request Entity Too Large를 가져옵니다.
오류 메시지
클라이언트 애플리케이션은 다음 응답 코드를 가져옵니다.
HTTP/1.1 413 Request Entity Too Large
또한 다음과 같은 오류 메시지가 표시될 수 있습니다.
{
"fault":{
"faultstring":"Body buffer overflow",
"detail":{
"errorcode":"protocol.http.TooBigBody"
}
}
}
가능한 원인
이 오류는 클라이언트 애플리케이션에서 HTTP 요청의 일부로 Apigee Edge로 전송한 페이로드 크기가 Apigee Edge에서 허용되는 한도보다 큰 경우에 발생합니다 .
이 오류가 발생하는 원인은 다음과 같습니다.
| 원인 | 설명 | 다음에 관한 문제 해결 안내 |
|---|---|---|
| 요청 페이로드 크기가 허용 한도보다 큼 | 클라이언트 애플리케이션에서 HTTP 요청의 일부로 Apigee Edge로 전송한 페이로드 크기가 Apigee Edge에서 허용되는 한도를 초과합니다. | Edge 퍼블릭 및 프라이빗 클라우드 사용자 |
| 압축 해제 후 요청 페이로드 크기가 허용 한도를 초과함 | 클라이언트 애플리케이션에서 Apigee Edge에 대한 HTTP 요청의 일부로 압축된 형식으로 전송한 페이로드 크기가 Apigee Edge로 압축 해제 시 허용된 한도를 초과합니다. | Edge 퍼블릭 및 프라이빗 클라우드 사용자 |
일반적인 진단 단계
다음 도구/기술 중 하나를 사용하여 이 오류를 진단하세요.
API 모니터링
API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.
- 적절한 역할이 있는 사용자로 Apigee Edge UI에 로그인합니다.
문제를 조사하려는 조직으로 전환합니다.
- 분석 > API 모니터링 > 조사 페이지로 이동합니다.
- 오류를 관찰한 특정 기간을 선택합니다.
- 프록시 필터를 선택하여 오류 코드의 범위를 좁힐 수도 있습니다.
- 시간을 기준으로 결함 코드를 표시합니다.
아래와 같이 오류 코드
protocol.http.TooBigBody및 상태 코드413가 있는 셀을 선택합니다.
오류 코드
protocol.http.TooBigBody에 관한 정보가 아래와 같이 표시됩니다.
- 로그 보기를 클릭하고 실패한 요청이 있는 행을 펼칩니다. 그런 다음 로그 창에서 아래와 같은 세부정보를 기록합니다.
비압축
시나리오 #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 도구를 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- 트레이스 세션을 사용 설정하고 다음 중 하나를 사용 설정합니다.
413 Request Entity Too Large오류가 발생할 때까지 기다립니다.- 문제를 재현할 수 있는 경우 API를 호출하고
413 Request Entity Too Large오류를 재현합니다.
Show all Flow Infos(모든 흐름 정보 표시)가 사용 설정되어 있는지 확인합니다.
- 실패한 요청 중 하나를 선택하고 트레이스를 검사합니다.
- Request Received from Client 단계로 이동합니다.
비압축
시나리오 #1: 압축되지 않은 형식으로 전송된 요청 페이로드
다음 정보를 참고하세요.
- Content-Encoding: 없음
- Content-Length:
15360204
압축
시나리오 #2: 압축된 형식으로 전송된 요청 페이로드
다음 정보를 참고하세요.
- 콘텐츠 인코딩:
gzip - Content-Length:
14969 - 콘텐츠 유형:
application/x-gzip
- trace의 여러 단계를 살펴보고 실패가 발생한 위치를 찾습니다.
일반적으로 다음과 같이 Request Received from Client 단계 후 흐름에서 오류를 확인할 수 있습니다.
- 트레이스에서 오류 값을 기록해 둡니다. 위의 샘플 trace는 다음을 보여줍니다.
- 오류:
Body buffer overflow - error.class:
com.apigee.errors.http.user.RequestTooLarge
- 오류:
Response Sent to Client로 이동하여 트레이스에서 오류 값을 기록합니다. 아래 샘플 트레이스는 다음을 보여줍니다.
- 오류:
413 Request Entity Too Large - 오류 콘텐츠:
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
- 오류:
- 추적에서 AX (애널리틱스 데이터 기록됨) 단계로 이동하여 클릭합니다.
단계 세부정보 섹션에서 변수 읽기까지 아래로 스크롤합니다.
- 다음을 나타내는 client.received.content.length 변수의 값을 확인합니다.
- 압축되지 않은 형식으로 전송될 요청 페이로드의 실제 크기
- 페이로드가 압축된 형식으로 전송될 때 Apigee에서 압축 해제될 때 요청 페이로드의 크기입니다. 이 시나리오에서 허용되는 한도 (10MB)의 값과 항상 동일합니다.
비압축
시나리오 #1: 압축되지 않은 형식의 페이로드 요청
client.received.content.length 변수:
15360204압축
시나리오 #2: 압축된 형식의 요청 페이로드
client.received.content.length 변수:
10489856 - 다음 표에서는 client.received.content.length 변수 값을 기준으로 두 가지 시나리오에서 Apigee에서
413오류를 반환하는 이유를 설명합니다.시나리오 client.received.content.length의 값 실패 원인 비압축 형식의 요청 페이로드 약 15MB 크기 > 허용되는 한도 10MB 압축된 형식의 요청 페이로드 약 10MB 압축 해제 시 크기 제한을 초과했습니다.
NGINX
NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.
- Private Cloud 사용자는 NGINX 액세스 로그를 사용하여 HTTP
413오류에 대한 주요 정보를 확인할 수 있습니다. NGINX 액세스 로그를 확인합니다.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log- 특정 기간 동안
413오류가 있는지 (과거에 문제가 발생한 경우) 또는 여전히413와 함께 실패하는 요청이 있는지 검색하여 확인합니다. - X-Apigee-fault-code 값과 일치하는 X-Apigee-fault-code 가 포함된
413오류가 있는 경우 X-Apigee-fault-code 의 값을 확인합니다.비압축
시나리오 #1 : 비압축 형식의 요청 페이로드 크기
NGINX 액세스 로그의 위 샘플 항목에는 X-Apigee-fault-code 및 X-Apigee-fault-code 에 대한 값이 다음과 같습니다.
응답 헤더 값 X-Apigee-fault-code protocol.http.TooBigBodyX-Apigee-fault-sourc policy요청 길이:
15360440(14.6MB > 허용 한도)을 확인합니다.압축
시나리오 #2 : 압축된 형식의 요청 페이로드 크기
NGINX 액세스 로그의 위 샘플 항목에는 X-Apigee-fault-code 및 X-Apigee-fault-code 에 대한 값이 다음과 같습니다.
응답 헤더 값 X-Apigee-fault-code protocol.http.TooBigBodyX-Apigee-fault-source policy요청 길이:
15264(14.9K < 허용 한도)을 확인합니다.이 시나리오에서는 요청이 압축된 형식으로 전송되었을 수 있고 Apigee Edge에 의한 압축 해제 시 한도를 초과했기 때문에 Apigee Edge는 요청 길이가 허용된 한도보다 낮더라도
413를 반환합니다.
원인: 요청 페이로드 크기가 허용된 제한보다 큽니다.
진단
- 시나리오 #1 (비압축)의 일반적인 진단 단계에 설명된 대로 API Monitoring, Trace 도구 또는 NGINX 액세스 로그를 사용하여 관찰된 오류의 결함 코드, 오류 소스, 요청 페이로드 크기를 확인합니다.
- 오류 소스의 값이
policy또는proxy이면 클라이언트 애플리케이션에서 Apigee로 보낸 요청 페이로드 크기가 Apigee Edge에서 허용되는 한도보다 크다는 의미입니다. - 1단계에서 결정한 대로 Request Payload Size(요청 페이로드 크기)를 확인합니다.
- 페이로드 크기가 허용 한도 10MB를 초과하면 오류가 발생한 것입니다.
- 허용되는 페이로드 크기가 10MB 미만인 경우 요청 페이로드가 압축된 형식으로 전달될 수 있습니다. 원인: 압축 해제 후 요청 페이로드 크기가 허용 한도를 초과함으로 이동
- 다음 단계에 따라 실제 요청을 검사하여 요청 페이로드 크기가 실제로 허용된 한도보다 10MB를 초과하는지 확인할 수도 있습니다.
- 클라이언트 애플리케이션에서 보낸 실제 요청에 액세스할 수 없는 경우 해결 방법으로 이동합니다.
- 클라이언트 애플리케이션에서 보낸 실제 요청에 액세스할 수 있는 경우 다음 단계를 따르세요.
- 요청에 전달된 페이로드 크기를 확인합니다.
- 페이로드의 크기가 Apigee Edge에서 허용되는 한도보다 크다면 이것이 문제의 원인입니다.
샘플 요청:
curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v
위의 경우
test15mbfile파일은 최대 15MB입니다. 다른 클라이언트를 사용하는 경우 클라이언트 로그를 가져와 전송 중인 페이로드 크기를 확인합니다.
해상도
해결 방법으로 이동합니다.
원인: 압축 해제 후 요청 페이로드 크기가 허용 한도를 초과합니다.
요청 페이로드가 압축 형식으로 전송되고 요청 헤더 Content-Encoding가 gzip, 로 설정된 경우 Apigee는 요청 페이로드를 압축 해제합니다. 압축 해제 프로세스 중에 Apigee에서 페이로드 크기가 10MB를 초과하면
허용된 한도를 초과하면 추가 압축 해제를 중지하고 즉시 413 Request Entity Too Large 오류 코드와 함께 413 Request Entity Too Large 응답을 전송합니다.protocol.http.TooBigBody
진단
- 시나리오 #2 (압축)의 일반적인 진단 단계에 설명된 대로 API Monitoring, Trace Tool 또는 NGINX 액세스 로그를 사용하여 관찰된 오류의 오류 코드, 결함 소스, 요청 페이로드 크기를 확인합니다.
- 오류 소스의 값이
policy또는proxy이면 클라이언트 애플리케이션에서 Apigee로 보낸 요청 페이로드 크기가 Apigee Edge에서 허용되는 한도보다 크다는 의미입니다. - 1단계에서 결정한 대로 요청 페이로드 크기를 확인합니다.
- 페이로드 크기가 허용 한도 10MB를 초과하면 오류가 발생한 것입니다.
- 허용되는 페이로드 크기가 10MB 미만인 경우 요청 페이로드가 압축된 형식으로 전달될 수 있습니다. 이 경우 압축된 요청 페이로드의 압축되지 않은 크기를 확인합니다.
- 클라이언트의 요청이 압축된 형식으로 전송되었고 압축되지 않은 크기가 다음 방법 중 하나를 사용하여 허용된 한도보다 큰지 확인할 수 있습니다.
Trace
Trace 도구를 사용해 유효성을 검사하려면 다음 단계를 따르세요.
실제 요청
실제 요청을 사용하여 유효성을 검사하려면 다음 안내를 따르세요.
- 클라이언트 애플리케이션에서 보낸 실제 요청에 액세스할 수 없는 경우 해결 방법으로 이동합니다.
- 클라이언트 애플리케이션에서 보낸 실제 요청에 액세스할 수 있는 경우 다음 단계를 따르세요.
- 요청에 전송된
Content-Encoding헤더와 함께 요청에 전달된 페이로드의 크기를 확인합니다. 압축되지 않은 페이로드 크기가 Apigee Edge에서 허용되는 한도를 초과하는지 확인하세요.
샘플 요청:
curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
위의 경우
test15mbfile.gz파일은 크기 제한보다 작지만, 압축되지 않은 파일test15mbfile의 크기는 약 15MB이고Content-Encoding헤더는gzip입니다.다른 클라이언트를 사용하는 경우 클라이언트 로그를 가져와 전송 중인 페이로드 크기를 확인하고
Content-Encoding헤더가gzip로 설정되어 있는지 확인합니다.
- 요청에 전송된
메시지 프로세서 로그
메시지 프로세서 로그를 사용하여 유효성을 검사하려면 다음 안내를 따르세요.
- Private Cloud 사용자는 메시지 프로세서 로그를 사용하여 HTTP
413오류에 대한 주요 정보를 확인할 수 있습니다. 메시지 프로세서 로그를 확인합니다.
/opt/apigee/var/log/edge-message-processor/logs/system.log특정 기간 동안
413오류가 있는지 (과거에 문제가 발생한 경우) 또는 여전히413와 함께 실패하는 요청이 있는지 검색하여 확인합니다.다음과 같은 검색 문자열을 사용할 수 있습니다.
grep -ri "chunkCount"
grep -ri "RequestTooLarge"
system.log에서 다음과 유사한 행이 표시됩니다(TotalRead및chunkCount은 경우에 따라 다를 수 있음).2021-07-06 13:29:57,544 NIOThread@1 ERROR HTTP.SERVICE - TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large. TotalRead 10489856 chunkCount 2570 2021-07-06 13:29:57,545 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: com.apigee.errors.http.user.RequestTooLarge : Body buffer overflow
- 압축 해제 과정 동안 메시지 프로세서는 총 읽기 바이트가 10MB를 초과한다고 판단하면 즉시 중지하고 다음 줄을 출력합니다.
Message is too large. TotalRead 10489856 chunkCount 2570
이는 요청 페이로드 크기가 10MB를 초과하고 크기가 10MB 한도를 초과하기 시작하면 오류 코드가
protocol.http.TooBigBody인 경우 Apigee에서RequestTooLarge오류를 발생시킨다는 것을 의미합니다.
해상도
크기 수정
옵션 #1 [권장]: 허용된 한도보다 큰 페이로드 크기를 전송하지 않도록 클라이언트 애플리케이션 수정
- 특정 클라이언트가 한도에 정의된 허용 한도보다 큰 요청 / 페이로드 크기를 보내는 이유를 분석합니다.
바람직하지 않은 경우 허용 한도보다 작게 요청 / 페이로드 크기를 전송하도록 클라이언트 애플리케이션을 수정하세요.
위에서 설명한 예시에서는 아래와 같이 크기가 더 작은 파일 (크기가 5MB인
test5mbfile페이로드)을 전달하여 문제를 해결할 수 있습니다.curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
- 허용 한도를 초과하는 요청/페이로드를 전송하려는 경우 다음 옵션으로 이동합니다.
서명된 URL 패턴
옵션 #2 [권장]: Apigee Java콜아웃 내에서 서명된 URL 패턴 사용
10MB보다 큰 페이로드의 경우 Apigee는 GitHub의 에지 콜아웃: 서명된 URL 생성기 예시에 설명된 대로 Apigee JavaCall 내에서 서명된 URL 패턴을 사용하는 것이 좋습니다.
스트리밍
옵션 #3 : 스트리밍 사용
API 프록시가 매우 큰 요청이나 응답을 처리해야 하는 경우 Apigee에서 스트리밍을 사용 설정할 수 있습니다.
CwC
옵션 #4 : CwC 속성을 사용하여 버퍼 한도 늘리기
이 옵션은 권장 옵션을 사용할 수 없는 경우에만 사용해야 합니다. 기본 크기가 증가하면 성능 문제가 발생할 수 있기 때문입니다.
Apigee는 요청 및 응답 페이로드 크기 한도를 늘릴 수 있는 CwC 속성을 제공합니다. 자세한 내용은 라우터 또는 메시지 프로세서의 메시지 크기 한도 설정을 참조하세요.
한도
Apigee는 클라이언트 애플리케이션과 백엔드 서버에서 Apigee Edge 한도의 Request/response size에 설명된 허용 한도를 초과하는 페이로드 크기를 전송하지 않을 것으로 예상합니다.
- Public Cloud 사용자인 경우 요청 및 응답 페이로드 크기의 최대 한도는 Apigee Edge 한도의
Request/response size에 대한 문서화된 것과 같습니다. - Private Cloud 사용자 의 경우 권장사항은 아니지만 요청 및 응답 페이로드 크기의 기본 한도를 수정했을 수 있습니다. 현재 한도를 확인하는 방법의 안내에 따라 최대 요청 페이로드 크기 한도를 확인할 수 있습니다.
현재 한도를 확인하는 방법
이 섹션에서는 HTTPRequest.body.buffer.limit 속성이 메시지 프로세서의 새 값으로 업데이트되었는지 확인하는 방법을 설명합니다.
- 메시지 프로세서 시스템의
/opt/apigee/edge-message- processor/conf디렉터리에서HTTPRequest.body.buffer.limit속성을 검색하고 다음 명령어를 사용하여 어떤 값이 설정되었는지 확인합니다.grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
- 위 명령어의 샘플 결과는 다음과 같습니다.
/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m
위의 출력 예에서
HTTPRequest.body.buffer.limit속성이http.properties의10m값으로 설정되어 있음을 알 수 있습니다.프라이빗 클라우드용 Apigee에 구성된 요청 페이로드 크기의 한도가 10MB임을 나타냅니다.
Apigee 지원의 지원이 더 필요하면 진단 정보를 수집해야 하는 경우로 이동하세요.
진단 정보 수집 필요
다음 진단 정보를 수집한 다음 Apigee Edge 지원팀에 문의하세요.
Public Cloud 사용자인 경우 다음 정보를 제공합니다.
- 조직 이름
- 환경 이름
- API 프록시 이름
413오류를 재현하는 데 사용된 전체 curl 명령어- API 요청에 대한 추적 파일
Private Cloud 사용자인 경우 다음 정보를 제공하세요.
- 실패한 요청에 대해 발견된 전체 오류 메시지
- 조직 이름
- 환경 이름
- API 프록시 번들
- 실패한 API 요청에 대한 추적 파일
413오류를 재현하는 데 사용된 전체 curl 명령어NGINX 액세스 로그
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log여기서 ORG, ENV, PORT#는 실제 값으로 대체됩니다.
- 메시지 프로세서 시스템 로그
/opt/apigee/var/log/edge-message-processor/logs/system.log