400 Nieprawidłowe żądanie – DecompressionFailureAtRequest

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 400 Bad Request z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest jako odpowiedź na interfejs API połączeń.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 400 Bad Request

Możesz też zobaczyć 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łowy i . obsługiwane przez Apigee Edge,

ALE

• Format ładunku wysyłany przez klienta w ramach żądania HTTP nie pasuje do formatu kodowania określonego w Content-Encoding

Dzieje się tak, ponieważ Apigee Edge nie dekoduje ładunku za pomocą podanego kodowania, ponieważ format ładunku nie jest w tym samym formacie co kodowanie określone w parametrze Nagłówek Content-Encoding.

Oto kilka przykładów obsługiwanych wartości Content-Encoding oraz sposób działania Apigee Edge oczekuje formatu ładunku w tych przypadkach:

Scenariusz	Content-Encoding	Oczekiwany format ładunku
Pojedyncze kodowanie	gzip	Format uniksowy gzip. Zobacz RFC1952 GZIP Format.
Pojedyncze kodowanie	Deflate	Ten format wykorzystuje strukturę zlib z algorytmem kompresji deflate. Zobacz RFC1950 i RFC1951.
Wielokrotne kodowanie	Wielokrotne kodowanie Jeśli na przykład kodowanie jest wykonywane 2 razy, może to być: gzip, deflate, gzip, deflate gzip, gzip deflate, gzip deflate, deflate	Do ładunku zastosowano wiele kodowania, w podanej kolejności, w jakiej występuje w nagłówku.

Możliwe przyczyny tego błędu są następujące:

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Format ładunku żądania nie pasuje do kodowania określonego w nagłówku Content-Encoding	Format ładunku żądania wysyłanego przez klienta nie jest zakodowany lub nie pasuje do kodowania określonego w nagłówku Content-Encoding.	Użytkownicy chmury publicznej i prywatnej Edge

Typowe kroki diagnostyki

Użyj jednego z tych narzędzi lub metod, aby zdiagnozować ten błąd:

Przyczyna: format ładunku żądania nie pasuje do określonego kodowania w nagłówku Content-Encoding

Domyślnie Apigee Edge zawsze dekompresuje ładunek, jeśli nagłówek żądania Content-Encoding zawiera prawidłowe i a obsługiwane kodowanie. Można więc oczekiwać, że format ładunku żądania powinien być zgodny z kodowaniem określonym w nagłówku żądania Content-Encoding. Ten błąd pojawia się w przypadku niezgodności.

Diagnostyka

1. Określ kod błędu i źródło błędu dla błędu zaobserwowanego za pomocą interfejsu API. Logi monitorowania, narzędzia śledzenia lub logi dostępu NGINX zgodnie z opisem w artykule Najczęstsze czynności diagnostyczne.
2. Jeśli kod błędu to messaging.adaptors.http.flow.DecompressionFailureAtRequest oraz Źródło błędu ma wartość policy lub proxy, a następnie wskazuje, że żądanie wysłane przez aplikację kliencką zawiera ładunek niepasujący do obsługiwane kodowanie określone w nagłówku żądania Content-Encoding.

3. Możesz określić niezgodność w ramach żądania HTTP za pomocą jednej z tych metod: metody:

   Komunikat o błędzie

   Aby przeprowadzić weryfikację przy użyciu komunikatu o błędzie:

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

      Przykładowy komunikat o błędzie:

      "faultstring":"Decompression failure at request"
      

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

   Śledzenie

   Aby przeprowadzić weryfikację za pomocą logu czasu:

   1. Ustal wartość nagłówka żądania Content-Encoding oraz właściwość error.cause za pomocą Trace zgodnie z opisem w sekcji Typowe kroki diagnostyki.

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

      • Kodowanie treści: gzip
      • error.cause: Not in GZIP format

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

   Rzeczywiste żądanie

   Aby przeprowadzić weryfikację na podstawie rzeczywistego żądania:

   Jeśli masz dostęp do faktycznego żądania zgłoszonego przez klienta aplikacji, a następnie wykonaj te czynności:

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

   3. Jeśli wartość nagłówka Content-Encoding znajduje się na liście jest obsługiwane kodowanie, ale format ładunku żądania nie pasuje do kodowania określonego w nagłówku Content-Encoding, to jest właśnie przyczyną problemu.

      Przykładowe żądanie:

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

      Powyższe przykładowe żądanie wysyła wartość gzip do funkcji Content-Encoding, który jest obsługiwane kodowanie w Apigee Edge. Jednak ładunek żądania request_payload.zip jest w formacie ZIP. W związku z tym prośba kończy się niepowodzeniem i otrzymuje kod stanu 400 Bad Request i kod błędu: messaging.adaptors.http.flow.DecompressionFailureAtRequest

   Logi procesora wiadomości

   Aby przeprowadzić weryfikację za pomocą logów procesora wiadomości:

   Jeśli jesteś użytkownikiem Private Cloud, możesz używać logów procesora wiadomości w celu ustalenia najważniejszych informacji o błędach HTTP 400.

   1. Ustal identyfikator wiadomości nieudanego żądania za pomocą monitorowania interfejsów API, narzędzia Trace lub dzienników dostępu NGINX, zgodnie z opisem w sekcji Typowe kroki diagnostyki.

   2. Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości:

      /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 ma 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 oznacza, że żądanie nie jest wysyłany w formacie GZIP, chociaż 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 ma 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)
      

      Linie java.util.zip.ZipException: incorrect header check oraz Caused by: java.util.zip.DataFormatException: incorrect header check w powyższym komunikacie o błędzie wskazuje, że ładunek żądania nie został wysłany w deflate i nie pasuje do kodowania określonego w Content-Encoding nagłówek deflate. W związku z tym Apigee Edge zgłasza wyjątek i zwraca kod stanu 400 z kod błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest do aplikacji klienckich.

Rozdzielczość

1. Jeśli nie ma potrzeby skompresowanego ładunku żądania w procesie serwera proxy interfejsu API w Apigee Edge i na serwerze backendu, nie przekazuj nagłówka Content-Encoding. Jeśli konieczne jest skompresowanie ładunku żądania, przejdź do kroku 2.
2. Upewnij się, że aplikacja kliencka zawsze wysyła to:
   • Dowolny obsługiwane kodowanie jako wartość nagłówka Content-Encoding w polu prośba
   • Ładunek żądania do Apigee Edge w obsługiwanym formacie pasuje do kodowania format określony w nagłówku Content-Encoding
3. W omówionym powyżej przykładzie ładunek żądania ma format ZIP, ale nagłówek żądania. określa Content-Encoding: gzip. Możesz rozwiązać problem, wysyłając prośbę nagłówek jako Content-Encoding: gzip, a ładunek żądania także w gzip format:

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

Specyfikacja

Apigee Edge wysyła kod stanu 400 Bad Request zawierający kod błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest zgodnie z poniższym RFC specyfikacje:

Specyfikacja
RFC 7231, sekcja 6.5.1
RFC 7231, sekcja 3.1.2.2

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, wejdź na Musi zbierać informacje diagnostyczne.

Musi zbierać informacje diagnostyczne

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

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

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

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

• Pełny komunikat o błędzie zaobserwowany dla nieudanych żądań
• Nazwa środowiska
• Pakiet serwera 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 przez wartości rzeczywiste.

• Dzienniki systemowe procesora wiadomości /opt/apigee/var/log/edge-message-processor/logs/system.log