400 잘못된 요청 - DecompressionFailureAtRequest

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. info

증상

클라이언트 애플리케이션은 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 헤더에 지정된 인코딩과 일치하지 않습니다.

기본적으로 Apigee Edge는 요청 헤더 Content-Encoding에 유효하고 지원되는 인코딩이 포함된 경우 항상 페이로드를 압축 해제합니다. 따라서 요청 페이로드의 형식은 요청 헤더 Content-Encoding에 지정된 인코딩과 일치해야 합니다. 불일치가 있으면 이 오류가 표시됩니다.

진단

1. 일반적인 진단 단계에 설명된 대로 API 모니터링, Trace 도구 또는 NGINX 액세스 로그를 사용하여 관찰된 오류의 오류 코드와 오류 소스를 확인합니다.
2. 오류 코드가 messaging.adaptors.http.flow.DecompressionFailureAtRequest이고 오류 소스의 값이 policy 또는 proxy이면 클라이언트 애플리케이션에서 보낸 요청에 요청 헤더 Content-Encoding에 지정된 지원되는 인코딩과 일치하지 않는 페이로드가 있음을 나타냅니다.

3. 다음 방법 중 하나를 사용하여 HTTP 요청의 일부로 불일치를 확인할 수 있습니다.

   오류 메시지

   오류 메시지를 사용하여 유효성을 검사하려면 다음 단계를 따르세요.

   1. Apigee Edge에서 수신한 전체 오류 메시지에 액세스할 수 있는 경우 faultstring를 참고하세요.

      샘플 오류 메시지:

      "faultstring":"Decompression failure at request"

   2. 위 오류 메시지에는 "Decompression failure at request"가 표시되어 Content-Encoding 헤더에 지정된 인코딩을 사용하여 request를 압축 해제할 수 없음을 나타냅니다.

   Trace

   Trace를 사용하여 검증하려면 다음 단계를 따르세요.

   1. 일반적인 진단 단계에 설명된 대로 Trace를 사용하여 요청 헤더 Content-Encoding 및 속성 error.cause의 값을 확인합니다.

   2. 샘플 트레이스의 값은 다음과 같습니다.

      • Content-Encoding: gzip
      • error.cause: Not in GZIP format

      요청 헤더 Content-Encoding의 값은 gzip이지만 요청 페이로드는 GZIP 형식이 아닙니다(error.cause에 표시됨). 따라서 Apigee Edge는 400 Bad Request 및 오류 코드 messaging.adaptors.http.flow.DecompressionFailureAtRequest로 응답합니다.

   실제 요청

   실제 요청을 사용하여 검증하려면 다음 단계를 따르세요.

   클라이언트 애플리케이션에서 보낸 실제 요청에 액세스할 수 있는 경우 다음 단계를 실행합니다.

   1. 요청 헤더 Content-Encoding에 전달된 값을 확인합니다.
   2. 요청의 일부로 전송된 페이로드의 형식을 확인합니다.

   3. Content-Encoding 헤더 값이 지원되는 인코딩 목록에 있지만 요청 페이로드 형식이 Content-Encoding 헤더에 지정된 인코딩과 일치하지 않으면 문제가 발생합니다.

      샘플 요청:

      curl -v "http://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.zip
      

      위 샘플 요청은 Apigee Edge에서 지원되는 인코딩인 Content-Encoding 헤더에 gzip 값을 전송합니다. 하지만 요청 페이로드 request_payload.zip는 ZIP 형식입니다. 따라서 이 요청은 400 Bad Request 상태 코드와 오류 코드 messaging.adaptors.http.flow.DecompressionFailureAtRequest로 인해 실패합니다.

   메시지 프로세서 로그

   메시지 프로세서 로그를 사용하여 유효성을 검사하려면 다음 단계를 따르세요.

   프라이빗 클라우드 사용자인 경우 메시지 프로세서 로그를 사용하여 HTTP 400 오류에 관한 주요 정보를 확인할 수 있습니다.

   1. 일반적인 진단 단계에 설명된 대로 API 모니터링, Trace 도구 또는 NGINX 액세스 로그를 사용하여 실패한 요청의 메시지 ID를 확인합니다.

   2. 메시지 프로세서 로그에서 메시지 ID를 검색합니다.

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. 다음 예외 중 하나가 표시됩니다.

      시나리오 #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 상태 코드를 반환합니다.

해상도

1. Apigee Edge의 API 프록시 흐름과 백엔드 서버에 압축된 요청 페이로드가 필요하지 않으면 헤더 Content-Encoding를 전달하지 마세요. 요청 페이로드를 압축해야 하는 경우 2단계로 이동합니다.
2. 클라이언트 애플리케이션이 항상 다음을 전송하는지 확인합니다.
   • 요청의 Content-Encoding 헤더 값으로 지원되는 인코딩 중 하나
   • Apigee Edge에 대한 요청 페이로드가 지원되는 형식이며 Content-Encoding 헤더에 지정된 인코딩 형식과 일치합니다.
3. 위에서 설명한 예시에서 요청 페이로드는 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 사양에 따라 오류 코드 messaging.adaptors.http.flow.DecompressionFailureAtRequest와 함께 상태 코드 400 Bad Request로 응답합니다.

Apigee 지원팀의 지원이 여전히 필요한 경우 진단 정보를 수집해야 함으로 이동하세요.

진단 정보 수집 필요

다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 문의합니다.

Public Cloud 사용자인 경우 다음 정보를 제공하세요.

• 조직 이름
• 환경 이름
• API 프록시 이름
• 400 오류를 재현하는 데 사용된 전체 curl 명령어
• API 요청의 추적 파일

프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요.

• 실패한 요청에 대해 확인된 전체 오류 메시지
• 환경 이름
• 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