400 Nieprawidłowe żądanie – DecompressionFailureAtRequest

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

W odpowiedzi na wywołania interfejsu API aplikacja kliencka otrzymuje kod stanu HTTP 400 Bad Request z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest .

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 400 Bad Request

Może też pojawić się komunikat o błędzie podobny do tego poniżej:

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

Możliwe przyczyny

Ten błąd występuje tylko wtedy, gdy:

• Kodowanie określone w nagłówku żądania HTTP Content-Encoding jest prawidłowe i  obsługiwane przez Apigee Edge.

BUT

• Format ładunku wysłanego przez klienta w ramach żądania HTTP nie jest zgodny z formatem kodowania określonym w nagłówku Content-Encoding .

Dzieje się tak, ponieważ Apigee Edge nie może zdekodować ładunku przy użyciu określonego kodowania, ponieważ format ładunku nie jest taki sam jak kodowanie określone w nagłówku Content-Encoding.

Oto kilka przykładów obsługiwanych wartości Content-Encoding i oczekiwanego formatu ładunku w Apigee Edge:

Możliwe przyczyny tego błędu:

Typowe etapy diagnostyki

Aby zdiagnozować ten błąd, użyj jednego z tych narzędzi lub technik:

Przyczyna: format ładunku żądania nie jest zgodny z kodowaniem określonym w nagłówku Content-Encoding.

Domyślnie Apigee Edge zawsze dekompresuje ładunek, jeśli nagłówek żądania Content-Encoding zawiera prawidłowe i obsługiwane kodowanie. Oczekuje się więc, że format ładunku żądania będzie zgodny z kodowaniem określonym w nagłówku żądania Content-Encoding. Jeśli wystąpi niezgodność, pojawi się ten błąd.

Diagnostyka

1. Określ kod błędu i źródło błędu zaobserwowanego błędu, korzystając z monitorowania interfejsu API, narzędzia do śledzenia lub logów dostępu NGINX, zgodnie z opisem w typowych krokach diagnostycznych.
2. Jeśli kod błędu to messaging.adaptors.http.flow.DecompressionFailureAtRequest, a źródło błędu ma wartość policy lub proxy, oznacza to, że żądanie wysłane przez aplikację kliencką zawiera ładunek, który nie pasuje do obsługiwanego kodowania określonego w nagłówku żądania Content-Encoding.

3. Niezgodność możesz określić w ramach żądania HTTP, korzystając z jednej z tych metod:

   Komunikat o błędzie

   Aby sprawdzić poprawność za pomocą komunikatu o błędzie:

   1. Jeśli masz dostęp do pełnego komunikatu o błędzie otrzymanego z Apigee Edge, zapoznaj się z faultstring.

      Przykładowy komunikat o błędzie:

      "faultstring":"Decompression failure at request"

   2. W powyższym komunikacie o błędzie wyświetla się "Decompression failure at request", co oznacza, że żądania nie można zdekompresować przy użyciu kodowania określonego w nagłówku Content-Encoding.

   Śledzenie

   Aby sprawdzić poprawność za pomocą śladu:

   1. Określ wartość nagłówka żądania Content-Encoding i właściwości error.cause za pomocą Trace zgodnie z opisem w artykule Typowe kroki diagnostyczne.

   2. Wartości z przykładowego śledzenia są następujące:

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

      Wartość w nagłówku żądania Content-Encoding to gzip, jednak ładunek żądania nie jest w formacie GZIP (co wskazuje error.cause). Dlatego Apigee Edge odpowiada kodem 400 Bad Request i kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Rzeczywista prośba

   Aby sprawdzić poprawność za pomocą rzeczywistego żądania:

   Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację klienta, wykonaj te czynności:

   1. Określ wartość przekazaną do nagłówka żądania Content-Encoding.
   2. Określ format ładunku wysyłanego w ramach żądania.

   3. Jeśli wartość nagłówka Content-Encoding znajduje się na liście obsługiwanych kodowań, ale format ładunku żądania nie jest zgodny z kodowaniem określonym w nagłówku Content-Encoding, to jest to przyczyną problemu.

      Przykładowe żądanie:

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

      W podanym wyżej przykładowym żądaniu wartość gzip jest wysyłana do nagłówka Content-Encoding, który jest obsługiwanym kodowaniem w Apigee Edge. Jednak ładunek żądaniarequest_payload.zip jest w formacie ZIP. Dlatego to żądanie kończy się niepowodzeniem i zwraca kod stanu 400 Bad Request oraz kod błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Dzienniki procesora komunikatów

   Aby przeprowadzić weryfikację za pomocą logów procesora komunikatów:

   Jeśli jesteś użytkownikiem chmury prywatnej, możesz użyć logów procesora komunikatów, aby określić kluczowe informacje o błędach HTTP 400.

   1. Określ identyfikator wiadomości żądania, które się nie powiodło, za pomocą narzędzia do monitorowania interfejsu API, narzędzia śledzenia lub dzienników dostępu NGINX zgodnie z opisem w artykule Typowe czynności diagnostyczne.

   2. Wyszukaj identyfikator wiadomości w logu procesora komunikatów:

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

   3. Zobaczysz jeden z tych wyjątków:

      Scenariusz 1

      Scenariusz 1. Gdy żądanie do interfejsu API zawiera nagłówek 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
      

      Wiersz java.util.zip.ZipException: Not in GZIP format w powyższym komunikacie o błędzie wskazuje, że ładunek żądania nie jest wysyłany w formacie GZIP, mimo że Content-Encoding jest określony jako gzip. Dlatego Apigee Edge zgłasza wyjątek i zwraca kod stanu 400 z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest do aplikacji klienckich.

      Scenariusz 2

      Scenariusz 2. Gdy żądanie do interfejsu API zawiera nagłówek 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)
      

      Wiersze java.util.zip.ZipException: incorrect header check i Caused by: java.util.zip.DataFormatException: incorrect header check w powyższym komunikacie o błędzie wskazują, że ładunek żądania nie jest wysyłany w formacie deflate i nie pasuje do kodowania określonego w nagłówku Content-Encoding deflate. Dlatego Apigee Edge zgłasza wyjątek i zwraca kod stanu 400 z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest do aplikacji klienckich.

Rozdzielczość

1. Jeśli w przepływie proxy interfejsu API w Apigee Edge i na serwerze backendu nie jest potrzebny skompresowany ładunek żądania, nie przekazuj nagłówka Content-Encoding. Jeśli chcesz skompresować ładunek żądania, przejdź do kroku 2.
2. Upewnij się, że aplikacja kliencka zawsze wysyła te informacje:
   • dowolne obsługiwane kodowanie jako wartość nagłówka Content-Encoding w żądaniu.
   • Ładunek żądania w obsługiwanym formacie do Apigee Edge jest zgodny z formatem kodowania określonym w nagłówku Content-Encoding.
3. W omówionym powyżej przykładzie ładunek żądania jest w formacie ZIP, ale nagłówek żądania określa Content-Encoding: gzip. Możesz rozwiązać ten problem, wysyłając nagłówek żądania jako Content-Encoding: gzip, a ładunek żądania również w formacie gzip:

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

Specyfikacja

Apigee Edge odpowiada kodem stanu 400 Bad Request z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest zgodnie ze specyfikacjami RFC:

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, zapoznaj się z sekcją Informacje diagnostyczne, które musisz zebrać.

musi zbierać informacje diagnostyczne;

Zbierz te informacje diagnostyczne, a potem skontaktuj się z zespołem pomocy Apigee Edge:

Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:

• Nazwa organizacji
• Nazwa środowiska
• Nazwa proxy interfejsu API
• Pełne polecenie curl użyte do odtworzenia błędu 400
• Plik śledzenia żądań do interfejsu API

Jeśli jesteś użytkownikiem chmury Private Cloud, podaj te informacje:

• Pełny komunikat o błędzie dotyczący żądań, które nie zostały zrealizowane
• Nazwa środowiska
• Pakiet proxy interfejsu API
• Plik śledzenia żądań do interfejsu API

• Logi dostępu NGINX/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Gdzie: ORG, ENV i PORT# są zastępowane rzeczywistymi wartościami.

• Dzienniki systemowe procesora komunikatów /opt/apigee/var/log/edge-message-processor/logs/system.log