현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보
증상
클라이언트 애플리케이션은 API 호출에 대한 응답으로 오류 코드 messaging.adaptors.http.flow.DecompressionFailureAtRequest
와 함께 HTTP 상태 코드 400 Bad Request
를 가져옵니다.
오류 메시지
클라이언트 애플리케이션은 다음 응답 코드를 가져옵니다.
HTTP/1.1 400 Bad Request
또한 아래와 유사한 오류 메시지가 표시될 수 있습니다.
{ "fault":{ "faultstring":"Decompression failure at request", "detail":{ "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest" } } }
가능한 원인
이 오류는 다음과 같은 경우에만 발생합니다.
- HTTP 요청 헤더
Content-Encoding
에 지정된 인코딩이 올바르고 Apigee Edge에서 지원됩니다. - HTTP 요청의 일부로 클라이언트가 전송한 페이로드 형식이
Content-Encoding
헤더에 지정된 인코딩 형식과 일치하지 않습니다.
그러나
페이로드의 형식이 Content-Encoding
헤더에 지정된 인코딩과 동일한 형식이 아니기 때문에 Apigee Edge가 지정된 인코딩을 사용하여 페이로드를 디코딩하지 못하기 때문입니다.
다음은 지원되는 Content-Encoding
값의 몇 가지 예시와 이러한 경우에 Apigee Edge에서 페이로드 형식으로 예상하는 방식입니다.
시나리오 | Content-Encoding | 예상 페이로드 형식 |
---|---|---|
단일 인코딩 | gzip | Unix RFC1952 GZIP 형식을 참고하세요. |
단일 인코딩 | 압축 해제하다 | 이 형식은 |
다중 인코딩 | 다중 인코딩 예를 들어 인코딩이 두 번 실행되는 경우 다음과 같을 수 있습니다.
|
헤더에 표시되는 지정된 순서로 페이로드에 다중 인코딩이 적용됩니다. |
이 오류가 발생할 수 있는 원인은 다음과 같습니다.
원인 | 설명 | 다음에 관한 문제 해결 안내 |
---|---|---|
요청 페이로드 형식이 Content-Encoding 헤더에 지정된 인코딩과 일치하지 않음 | 클라이언트에서 보낸 요청 페이로드 형식이 인코딩되지 않았거나 Content-Encoding 헤더에 지정된 인코딩과 일치하지 않습니다. |
Edge 퍼블릭 및 프라이빗 클라우드 사용자 |
일반적인 진단 단계
다음 도구/기술 중 하나를 사용하여 이 오류를 진단하세요.
API 모니터링
API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.
- 적절한 역할이 있는 사용자로 Apigee Edge UI에 로그인합니다.
문제를 조사하려는 조직으로 전환합니다.
- 분석 > API 모니터링 > 조사 페이지로 이동합니다.
- 오류를 관찰한 특정 기간을 선택합니다.
- 프록시 필터가 모두로 설정되어 있는지 확인합니다.
- 시간을 기준으로 결함 코드를 표시합니다.
아래와 같이 오류 코드가
messaging.adaptors.http.flow.DecompressionFailureAtRequest
인 셀을 선택합니다.( 더 큰 이미지 보기)
오류 코드
messaging.adaptors.http.flow.DecompressionFailureAtRequest
에 관한 정보가 아래와 같이 표시됩니다.( 더 큰 이미지 보기)
로그 보기를 클릭하고
400
오류와 함께 실패한 행을 펼칩니다.( 더 큰 이미지 보기)
- 로그 창에서 다음 세부정보를 확인합니다.
- 상태 코드:
400
- 결함 소스:
proxy
- 오류 코드:
messaging.adaptors.http.flow.DecompressionFailureAtRequest
.
- 상태 코드:
- 오류 소스의 값이
proxy
이면 요청 페이로드 형식이Content-Encoding
헤더에 지정된 지원되는 인코딩과 일치하지 않음을 나타냅니다.
추적 도구
Trace 도구를 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- trace 세션과 다음 중 하나를 사용 설정합니다.
400 Bad Request
오류가 발생할 때까지 기다립니다.- 문제를 재현할 수 있는 경우 API를 호출하고
400 Bad Request
를 재현합니다.
Show all FlowInfos(모든 FlowInfos 표시)가 사용 설정되어 있는지 확인합니다.
- 실패한 요청 중 하나를 선택하고 트레이스를 검사합니다.
- trace의 여러 단계를 살펴보고 오류가 발생한 위치를 찾습니다.
일반적으로 아래와 같이 Request Received from Client 단계 직후에 흐름에서 오류를 확인할 수 있습니다.
( 더 큰 이미지 보기)
-
트레이스의 속성 값을 기록해 둡니다.
- 오류:
Decompression failure at request
- error.class:
com.apigee.rest.framework.BadRequestException
- error.cause:
Not in GZIP format
error.cause는 요청 페이로드가 GZIP 형식이 아님을 나타냅니다. 이는 Apigee Edge에서 요청 페이로드가
Content-Encoding
헤더에 지정된 GZIP 형식일 것으로 예상했음을 의미합니다. - 오류:
요청 헤더
Content-Encoding
의 값을 확인합니다. 이를 위해 아래와 같이 Request Received from Client 단계로 이동합니다.( 더 큰 이미지 보기)
요청 헤더
Content-Encoding
의 값은 실제로gzip
입니다.위의 샘플 트레이스는 요청 헤더
Content-Encoding
에 지정된 인코딩이gzip
이지만 요청 페이로드가 GZIP 형식이 아님을 보여줍니다. 따라서 Apigee는 gzip을 사용하여 페이로드의 압축을 풀 수 없으며Decompression failure at request
오류를 반환합니다.- 탐색하여 Apigee Edge에서 반환한 상태 코드와 오류 메시지를 기록합니다.
Response Sent to Client 단계로 전달합니다.
( 더 큰 이미지 보기)
트레이스에서 다음과 같은 세부정보를 확인합니다.
- 상태 코드:
400 Bad Request
. - 오류 콘텐츠:
{"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}
- 상태 코드:
추적에서 AX (애널리틱스 데이터 기록됨) 단계로 이동하여 클릭합니다.
- 단계 세부정보, 오류 헤더 섹션까지 아래로 스크롤하여 아래와 같이 X-Apigee-fault-code 및 X-Apigee-fault-source의 값을 확인합니다.
( 더 큰 이미지 보기)
- X-Apigee-fault-code 및 X-Apigee-fault-source의 값이
messaging.adaptors.http.flow.DecompressionFailureAtRequest
및policy
로 표시되어 요청 페이로드 형식이Content-Encoding
헤더에 지정된 인코딩과 일치하지 않았음을 나타냅니다.응답 헤더 값 X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
X-Apigee-fault-source policy
NGINX
NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.
- Private Cloud 사용자는 NGINX 액세스 로그를 사용하여 HTTP
400
오류에 대한 주요 정보를 확인할 수 있습니다. NGINX 액세스 로그를 확인합니다.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
여기서 ORG, ENV, PORT#는 실제 값으로 대체됩니다.
- 특정 기간 동안
400
오류가 있는지(과거에 문제가 발생한 경우) 또는400
와 함께 여전히 실패하는 요청이 있는지 검색합니다. messaging.adaptors.http.flow.DecompressionFailureAtRequest
값과 일치하는 X-Apigee-fault-code가 포함된400
오류가 발견되면 X-Apigee-fault-source의 값을 확인합니다.NGINX 액세스 로그의 샘플 400 오류:
NGINX 액세스 로그의 위 샘플 항목에는 X-Apigee-fault-code 및 X-Apigee-fault-code 에 대한 값이 다음과 같습니다.
응답 헤더 값 X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
X-Apigee-fault-source policy
원인: 요청 페이로드 형식이 Content-Encoding 헤더에 지정된 인코딩과 일치하지 않음
기본적으로 Apigee Edge는 요청 헤더 Content-Encoding
에 유효하고
지원되는 인코딩이 포함되어 있으면 항상 페이로드를 압축 해제합니다. 따라서 요청 페이로드의 형식은 요청 헤더 Content-Encoding
에 지정된 인코딩과 일치해야 합니다.
일치하지 않는 경우 이 오류가 표시됩니다.
진단
- 일반적인 진단 단계에 설명된 대로 API Monitoring, Trace 도구 또는 NGINX 액세스 로그를 사용하여 관찰된 오류의 오류 코드 및 오류 소스를 확인합니다.
- 오류 코드가
messaging.adaptors.http.flow.DecompressionFailureAtRequest
이고 오류 소스의 값이policy
또는proxy
이면 클라이언트 애플리케이션에서 전송한 요청에 요청 헤더Content-Encoding
에 지정된 지원되는 인코딩과 일치하지 않는 페이로드가 있음을 나타냅니다. 다음 메서드 중 하나를 사용하여 HTTP 요청의 일부로 불일치를 확인할 수 있습니다.
오류 메시지
오류 메시지를 사용하여 유효성을 검사하려면 다음 안내를 따르세요.
-
Apigee Edge에서 받은 전체 오류 메시지에 액세스할 수 있는 경우
faultstring
를 참조하세요.오류 메시지 샘플:
"faultstring":"Decompression failure at request"
- 위의 오류 메시지에는 요청을
Content-Encoding
헤더에 지정된 인코딩을 사용하여 압축 해제할 수 없음을 의미하는"Decompression failure at request"
가 표시됩니다.
Trace
Trace를 사용하여 유효성을 검사하려면 다음 안내를 따르세요.
- 일반적인 진단 단계에 설명된 대로 Trace를 사용하여 요청 헤더 Content-Encoding의 값과 error.cause 속성을 확인합니다.
샘플 트레이스의 값은 다음과 같습니다.
- 콘텐츠 인코딩:
gzip
- error.cause:
Not in GZIP format
요청 헤더 Content-Encoding의 값은 gzip이지만 요청 페이로드는 GZIP 형식이 아닙니다(error.cause로 표시). 따라서 Apigee Edge는
400 Bad Request
및 오류 코드messaging.adaptors.http.flow.DecompressionFailureAtRequest
로 응답합니다.- 콘텐츠 인코딩:
실제 요청
실제 요청을 사용하여 유효성을 검사하려면 다음 안내를 따르세요.
클라이언트 애플리케이션에서 보낸 실제 요청에 액세스할 수 있는 경우 다음 단계를 수행합니다.
- 요청 헤더
Content-Encoding
에 전달되는 값을 결정합니다. - 요청의 일부로 전송된 페이로드의 형식을 확인합니다.
Content-Encoding
헤더의 값이 지원되는 인코딩 목록에 있지만 요청 페이로드의 형식이Content-Encoding
헤더에 지정된 인코딩과 일치하지 않으면 이것이 문제의 원인입니다.샘플 요청:
curl -v "http://HOSTALIAS/v1/testgzip"
-H "Content-Encoding: gzip"
-X POST -d @request_payload.zip위의 샘플 요청은
gzip
값을 Apigee Edge에서 지원되는 인코딩인Content-Encoding
헤더로 전송합니다. 하지만 요청 페이로드request_payload.zip
은 ZIP 형식입니다. 따라서 이 요청은 실패하고400 Bad Request
상태 코드 및 오류 코드messaging.adaptors.http.flow.DecompressionFailureAtRequest
이 표시됩니다.
메시지 프로세서 로그
메시지 프로세서 로그를 사용하여 유효성을 검사하려면 다음 안내를 따르세요.
Private Cloud 사용자는 메시지 프로세서 로그를 사용하여 HTTP
400
오류에 대한 주요 정보를 확인할 수 있습니다.- 일반적인 진단 단계에 설명된 대로 API Monitoring, Trace 도구 또는 NGINX 액세스 로그를 사용하여 실패한 요청의 메시지 ID를 확인합니다.
메시지 프로세서 로그에서 메시지 ID를 검색합니다.
/opt/apigee/var/log/edge-message-processor/logs/system.log
다음 예외 중 하나가 표시됩니다.
시나리오 #1
시나리오 #1: API 요청에 Content-Encoding: gzip 헤더가 있는 경우
2021-07-28 10:21:16,861 NIOThread@0 ERROR HTTP.SERVER - HTTPServer$Context.onInputException() : Message id:rt-57-1 SSLClientChannel[Accepted: Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0 bytesWritten=28764 age=2739893ms lastIO=0ms isOpen=true.onExceptionRead exception: {} java.util.zip.ZipException: Not in GZIP format 2021-07-28 10:21:16,862 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/test, message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format, context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted: Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0 bytesWritten=28764 age=2739894ms lastIO=0ms isOpen=true) 2021-07-28 10:21:16,862 NIOThread@0 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception
java.util.zip.ZipException: Not in GZIP format
occurred while writing to channel null 2021-07-28 10:21:16,863 NIOThread@0 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.util.zip.ZipException: Not in GZIP format위의 오류 메시지에서
java.util.zip.ZipException: Not in GZIP format
줄은Content-Encoding
가 gzip으로 지정되었지만 요청 페이로드가 GZIP 형식으로 전송되지 않았음을 나타냅니다. 따라서 Apigee Edge는 예외를 발생시키고 오류 코드가messaging.adaptors.http.flow.DecompressionFailureAtRequest
인400
상태 코드를 클라이언트 애플리케이션에 반환합니다.시나리오 #2
시나리오 #2: API 요청에 Content-Encoding: deflate 헤더가 있는 경우
2021-07-28 15:26:31,893 NIOThread@1 ERROR HTTP.SERVER - HTTPServer$Context.onInputException() : Message id:rt-47875-1 SSLClientChannel[Accepted: Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0 bytesWritten=37230 age=3498856ms lastIO=1ms isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: incorrect header check
….Caused by: java.util.zip.DataFormatException: incorrect header check
.. 2021-07-28 15:26:31,894 NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/test, message Id:rrt-47875-1, exception:java.util.zip.ZipException: incorrect header check, context:Context@69b3ac45 input=ClientInputChannel(SSLClientChannel[Accepted: Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276 useCount=1 byt esRead=0 bytesWritten=37230 age=3498856ms lastIO=1ms isOpen=true)위 오류 메시지의
java.util.zip.ZipException: incorrect header check
및Caused by: java.util.zip.DataFormatException: incorrect header check
행은 요청 페이로드가 deflate 형식으로 전송되지 않으며 deflate의Content-Encoding
헤더에 지정된 인코딩과 일치하지 않음을 나타냅니다. 따라서 Apigee Edge는 예외를 발생시키고 오류 코드가messaging.adaptors.http.flow.DecompressionFailureAtRequest
인400
상태 코드를 클라이언트 애플리케이션에 반환합니다.
-
해상도
- Apigee Edge 및 백엔드 서버의 API 프록시 흐름에 압축된 요청 페이로드가 필요하지 않으면
Content-Encoding
헤더를 전달하지 마세요. 요청 페이로드를 압축해야 하는 경우 2단계로 이동합니다. - 클라이언트 애플리케이션이 항상 다음을 전송하는지 확인합니다.
- 요청의
Content-Encoding
헤더 값으로 사용되는 지원되는 인코딩 - Apigee Edge에 지원되는 형식의 요청 페이로드는
Content-Encoding
헤더에 지정된 인코딩 형식과 일치합니다.
- 요청의
- 위에 설명된 예시에서 요청 페이로드는 ZIP 형식이지만 요청 헤더는
Content-Encoding: gzip
를 지정합니다. 요청 헤더를Content-Encoding: gzip
으로 전송하고 요청 페이로드도gzip
형식으로 전송하면 문제를 해결할 수 있습니다.curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
사양
Apigee Edge는 다음 RFC 사양에 따라 400 Bad Request
상태 코드로 오류 코드 messaging.adaptors.http.flow.DecompressionFailureAtRequest
로 응답합니다.
사양 |
---|
RFC 7231, 섹션 6.5.1 |
RFC 7231, 섹션 3.1.2.2 |
Apigee 지원의 도움이 더 필요하면 진단 정보 수집 필수로 이동하세요.
진단 정보 수집 필요
다음 진단 정보를 수집한 다음 Apigee Edge 지원팀에 문의하세요.
Public Cloud 사용자인 경우 다음 정보를 제공합니다.
- 조직 이름
- 환경 이름
- API 프록시 이름
400
오류를 재현하는 데 사용된 전체curl
명령어- API 요청에 대한 추적 파일
Private Cloud 사용자인 경우 다음 정보를 제공하세요.
- 실패한 요청에 대해 발견된 전체 오류 메시지
- 환경 이름
- API 프록시 번들
- API 요청에 대한 추적 파일
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