400 잘못된 요청 - DecompressionFailureAtRequest

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보

증상

클라이언트 애플리케이션이 오류 코드와 함께 HTTP 상태 코드 400 Bad Request를 가져옵니다. messaging.adaptors.http.flow.DecompressionFailureAtRequest API에 대한 응답으로 사용 있습니다.

오류 메시지

클라이언트 애플리케이션은 다음과 같은 응답 코드를 받습니다. 

HTTP/1.1 400 Bad Request

또한 아래와 유사한 오류 메시지가 표시될 수도 있습니다. 

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

가능한 원인

이 오류는 다음과 같은 경우에만 발생합니다.

  • HTTP 요청 헤더 Content-Encoding에 지정된 인코딩 는 유효하며 <ph type="x-smartling-placeholder"></ph> 지원이 될 수 있으며

    • 그러나

  • 클라이언트가 HTTP 요청의 일부로 전송한 페이로드 형식은 Content-Encoding 헤더에 지정된 인코딩 형식과 일치

이는 Apigee Edge가 지정된 인코딩을 사용하여 페이로드를 디코딩하지 못하기 때문입니다. 형식이 Content-Encoding 헤더.

<ph type="x-smartling-placeholder">

지원되는 Content-Encoding 값의 몇 가지 예시와 Apigee Edge가 작동하는 방식은 다음과 같습니다. 는 페이로드 형식이 다음과 같을 것으로 예상합니다.

시나리오 Content-Encoding 예상 페이로드 형식
단일 인코딩 gzip

Unix gzip 형식

자세한 내용은 <ph type="x-smartling-placeholder"></ph> RFC1952 GZIP 형식

단일 인코딩 수축하다

이 형식은 무손실 압축 알고리즘과 함께 zlib 구조를 사용합니다.

를 참조하세요. RFC1950 및 <ph type="x-smartling-placeholder"></ph> RFC1951.
다중 인코딩

다중 인코딩

예를 들어 인코딩이 두 번 실행되는 경우 다음과 같습니다.

  • gzip, 압축 해제
  • gzip, gzip
  • 압축, gzip
  • deflate, deflate
 다중 인코딩이 헤더에 표시되는 대로 페이로드에 지정된 순서대로 적용됩니다.

이 오류가 발생할 수 있는 원인은 다음과 같습니다.

원인 설명 다음에 관한 문제 해결 안내
<ph type="x-smartling-placeholder"></ph> 요청 페이로드 형식이 Content-Encoding 헤더에 지정된 인코딩과 일치하지 않습니다. 클라이언트가 보낸 요청 페이로드의 형식이 인코딩되지 않았거나 Content-Encoding 헤더에 지정된 인코딩과 일치합니다. 에지 퍼블릭 및 프라이빗 클라우드 사용자

일반적인 진단 단계

다음 도구/기술 중 하나를 사용하여 이 오류를 진단합니다.

API 모니터링

<ph type="x-smartling-placeholder">

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

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

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

  3. 분석 > API 모니터링 > 조사 페이지를 엽니다.
  4. 오류가 관찰된 특정 기간을 선택합니다.
  5. 프록시 필터가 전체로 설정되어 있는지 확인합니다.
  6. 시간을 기준으로 결함 코드를 표시합니다.

  7. 오류 코드가 messaging.adaptors.http.flow.DecompressionFailureAtRequest인 셀을 선택하세요. 다음과 같습니다.

    ( 더 크게 보기)

  8. 오류 코드에 대한 정보 messaging.adaptors.http.flow.DecompressionFailureAtRequest는 아래와 같이 표시됩니다.

    ( 더 크게 보기)

  9. 로그 보기를 클릭하고 400 오류가 있는 행을 펼칩니다.

    ( 더 크게 보기)

  10. 로그 창에서 다음 세부정보를 확인합니다. <ph type="x-smartling-placeholder">
      </ph>
    • 상태 코드: 400
    • 오류 소스: proxy
    • 오류 코드: messaging.adaptors.http.flow.DecompressionFailureAtRequest.
  11. 결함 소스의 값이 proxy이면 요청 페이로드 형식이 <ph type="x-smartling-placeholder"></ph> 지원되는 인코딩이 Content-Encoding 헤더에 지정되어 있어야 합니다.

추적 도구

<ph type="x-smartling-placeholder">

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

  1. 추적 세션 사용 설정 그리고 다음 중 한 가지 조건 충족. <ph type="x-smartling-placeholder">
      </ph>
    1. 400 Bad Request 오류가 발생할 때까지 기다립니다.
    2. 문제를 재현할 수 있다면 API를 호출하고 재현합니다. 400 Bad Request

  2. 모든 FlowInfos 표시가 사용 설정되어 있는지 확인합니다.

  3. 실패한 요청 중 하나를 선택하고 trace를 검토합니다.
  4. 추적의 여러 단계를 살펴보고 장애가 발생한 위치 찾기 수 있습니다.

  5. 일반적으로 Request Received from Client(클라이언트로부터 수신된 요청) 단계를 따릅니다.

    ( 더 크게 보기)

  6. 트레이스의 속성 값을 확인합니다.

    • 오류: Decompression failure at request
    • error.class: com.apigee.rest.framework.BadRequestException
    • error.cause: Not in GZIP format

    error.cause는 요청 페이로드가 GZIP 형식이 아님을 명시합니다. 이는 Apigee Edge가 요청 페이로드가 GZIP 형식일 것으로 예상했음을 의미합니다. Content-Encoding 헤더에 지정되었을 때처럼 말이죠.

  7. 요청 헤더 Content-Encoding의 값을 결정합니다. 이를 위해 아래와 같이 Request Received from Client 단계로 이동합니다.

    ( 더 크게 보기)

    요청 헤더 Content-Encoding의 값은 gzip

    위의 샘플 trace는 요청 헤더에 지정된 인코딩이 Content-Encoding가 gzip입니다. 요청 페이로드는 GZIP 형식이 아닙니다. 따라서 Apigee는 다음 명령어를 사용하여 페이로드의 압축을 풀 수 없습니다. gzip으로 압축하고 Decompression failure at request 오류를 반환합니다.

  8. 다음 페이지로 이동하여 Apigee Edge에서 반환된 상태 코드와 오류 메시지를 확인하세요.

    아래와 같이 트레이스의 Response Sent to Client 단계로 전달합니다.

    ( 더 크게 보기)

    trace에서 다음 세부정보를 확인합니다.

    • 상태 코드: 400 Bad Request.
    • 오류 콘텐츠: <ph type="x-smartling-placeholder">{"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}</ph>

  9. 트레이스에서 AX (기록된 애널리틱스 데이터) 단계로 이동합니다. 클릭합니다.

  10. 아래로 스크롤하여 단계 세부정보, 오류 헤더 섹션으로 이동한 다음 X-Apigee-fault-code 및 X-Apigee-fault-source의 값을 결정합니다. 다음과 같습니다.

    ( 더 크게 보기)

  11. 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

<ph type="x-smartling-placeholder">

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

  1. Private Cloud 사용자인 경우 NGINX 액세스 로그를 사용하여 HTTP 400 오류에 대한 주요 정보를 확인할 수 있습니다.

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

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

    위치: ORG, ENV, PORT#는 실제 값으로 대체됩니다.

  3. 특정 기간 동안 400 오류가 있는지 검색합니다. (과거에 문제가 발생한 경우) 또는 여전히 400

  4. X-Apigee-fault-code에서 400 오류가 발견된 경우 messaging.adaptors.http.flow.DecompressionFailureAtRequest의 값과 일치 그런 다음 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에는 유효한 및 <ph type="x-smartling-placeholder"></ph> 지원되는 인코딩을 사용해야 합니다. 따라서 요청 페이로드의 형식은 요청 헤더 Content-Encoding에 지정된 인코딩과 일치해야 합니다. 불일치가 있는 경우 이 오류가 표시됩니다.

진단

  1. API를 사용하여 관찰된 오류의 결함 코드 및 오류 소스 확인 다음 도움말에 설명된 대로 Monitoring, 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 헤더.

    Trace

    Trace를 사용하여 검사하려면 다음 안내를 따르세요.

    1. 요청 헤더 Content-Encoding의 값과 Trace를 사용한 error.cause 속성 일반적인 진단 단계

    2. 샘플 trace의 값은 다음과 같습니다.

      • 콘텐츠 인코딩: 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 헤더의 값이 <ph type="x-smartling-placeholder"></ph> 지원되는 인코딩이지만 요청 페이로드의 형식은 Content-Encoding 헤더에 지정된 인코딩과 일치합니다. 그것이 문제의 원인입니다

      샘플 요청:

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

      위의 샘플 요청은 gzip 값을 Content-Encoding 헤더로, <ph type="x-smartling-placeholder"></ph> 지원되는 인코딩을 참고하세요. 하지만 요청 페이로드는 request_payload.zip은(는) ZIP 형식입니다. 따라서 이 요청은 400 Bad Request 상태 코드 및 오류 코드와 함께 실패합니다. messaging.adaptors.http.flow.DecompressionFailureAtRequest

    메시지 프로세서 로그

    <ph type="x-smartling-placeholder">

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

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

    1. API 모니터링, Trace 도구, 일반적인 진단 단계에 설명된 대로 NGINX 액세스 로그를 사용할 수 있습니다.

    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으로 지정됩니다 따라서 Apigee Edge는 예외를 발생시키고 오류 코드가 있는 400 상태 코드 반환 messaging.adaptors.http.flow.DecompressionFailureAtRequest 클라이언트 애플리케이션에 배포될 수 있습니다

      시나리오 #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는 예외가 발생하고 다음과 함께 400 상태 코드를 반환합니다. 오류 코드 messaging.adaptors.http.flow.DecompressionFailureAtRequest 클라이언트 애플리케이션에 배포될 수 있습니다

해상도

  1. Apigee Edge의 API 프록시 흐름에 압축된 요청 페이로드가 필요하지 않은 경우 백엔드 서버에서 사용하는 경우 헤더 Content-Encoding를 전달하지 마세요. 요청 페이로드를 압축해야 하는 경우 2단계로 이동합니다.
  2. 클라이언트 애플리케이션이 항상 다음을 전송하는지 확인합니다. <ph type="x-smartling-placeholder">
      </ph>
    • 다음 중 하나 <ph type="x-smartling-placeholder"></ph> Content-Encoding 헤더 값으로 요청
    • Apigee Edge에 지원되는 형식의 요청 페이로드가 인코딩과 일치합니다. Content-Encoding 헤더에 지정된 형식
  3. 위에 설명된 예에서 요청 페이로드는 ZIP 형식이지만 요청 헤더는 Content-Encoding: gzip는 지정합니다. 요청을 전송하여 문제를 해결할 수 있습니다. 헤더를 Content-Encoding: gzip로 설정하고 요청 페이로드도 gzip에 지정 형식: <ph type="x-smartling-placeholder">
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
    </ph> <ph type="x-smartling-placeholder">

사양

Apigee Edge가 오류 코드와 함께 상태 코드 400 Bad Request로 응답합니다. 다음 RFC에 따른 messaging.adaptors.http.flow.DecompressionFailureAtRequest 사양:

사양
<ph type="x-smartling-placeholder"></ph> RFC 7231, 섹션 6.5.1
<ph type="x-smartling-placeholder"></ph> RFC 7231, 섹션 3.1.2.2

Apigee 지원팀의 도움이 더 필요하면 로 이동하세요. 진단 정보를 수집해야 합니다.

진단 정보 수집 필요

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

퍼블릭 클라우드 사용자인 경우 다음 정보를 입력합니다.

  • 조직 이름
  • 환경 이름
  • 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