400 Nieprawidłowe żądanie – DecompressionFailureAtRequest

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

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żesz też zobaczyć komunikat o błędzie podobny do tego:

{
   "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,

ALE

• Format ładunku wysłany przez klienta w ramach żądania HTTP nie pasuje do formatu kodowania określonego w nagłówku 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 nagłówku Content-Encoding.

Oto kilka przykładów obsługiwanych wartości Content-Encoding i informacje o tym, jak Apigee Edge oczekuje formatu ładunku w takich przypadkach:

Scenariusz	Content-Encoding	Oczekiwany format ładunku
Pojedyncze kodowanie	gzip	Format Unix gzip. Zobacz Format GZIP w standardzie RFC1952.
Pojedyncze kodowanie	deflate	Ten format wykorzystuje strukturę zlib z algorytmem kompresji deflate. Zobacz RFC1950 i RFC1951..
Wiele kodowania	Wiele kodowania Jeśli na przykład kodowanie zostało wykonane dwukrotnie, może to wyglądać tak: gzip, deflate gzip, gzip deflate, gzip deflate, deflate	Do ładunku zastosowano wiele kodowania w takiej kolejności, w jakiej wyświetla się w nagłówku.

Możliwe przyczyny tego błędu:

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 usługi Edge

Najczęstsze kroki diagnostyki

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

Przyczyna: format ładunku żądania nie pasuje do kodowania określonego 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. Dlatego format ładunku żądania powinien być zgodny z kodowaniem określonym w nagłówku żądania Content-Encoding. Jeśli występuje niezgodność, pojawia się ten błąd.

Diagnostyka

1. Znajdź kod błędu i źródło błędu dla błędu zaobserwowanego przy użyciu interfejsu API Monitoring, narzędzia do śledzenia lub logów dostępu NGINX zgodnie z opisem w częstych krokach diagnostyki.
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 sprawdzić w żądaniu HTTP, korzystając z jednej z tych metod:

   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, zapoznaj się z dokumentem 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 żądanie nie mogło zostać zdekompresowane za pomocą kodowania określonego w nagłówku Content-Encoding.

   Trace

   Aby sprawdzić poprawność danych za pomocą logu czasu:

   1. Ustal wartość nagłówka żądania Content-Encoding i właściwości error.cause za pomocą funkcji Trace zgodnie z opisem w częstych krokach 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, ale ładunek żądania nie jest w formacie GZIP (jak wskazuje error.cause). Dlatego Apigee Edge w odpowiedzi wysyła 400 Bad Request i kod 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ę kliencką, 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ługiwanego kodowania, ale format ładunku żądania nie pasuje do kodowania określonego w nagłówku Content-Encoding, to jest 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 nagłówka Content-Encoding, które jest obsługiwanym kodowaniem w Apigee Edge. Ładunek żądania request_payload.zip jest jednak w formacie ZIP. Dlatego to żądanie zawiera kod stanu 400 Bad Request i kod błędu: messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Logi procesora wiadomości

   Aby sprawdzić poprawność danych za pomocą dzienników procesora wiadomości:

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

   1. Ustal identyfikator wiadomości niezrealizowanego żądania za pomocą monitorowania interfejsu API, narzędzia do śledzenia lub logów dostępu NGINX zgodnie z opisem w częstych krokach diagnostyki.

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

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

   3. Występuje jeden z tych wyjątków:

      Scenariusz 1

      Scenariusz 1. Żą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 ładunek żądania nie został wysłany w formacie GZIP, chociaż Content-Encoding jest określony jako gzip. Dlatego Apigee Edge zgłasza wyjątek i zwraca aplikacjom klienckim kod stanu 400 z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest.

      Scenariusz 2

      Scenariusz 2. Żą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)
      

      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 został wysłany w formacie deflate i nie pasuje do kodowania określonego w nagłówku Content-Encoding tagu deflate. Dlatego Apigee Edge zgłasza wyjątek i zwraca aplikacjom klienckim kod stanu 400 z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest.

Rozdzielczość

1. Jeśli nie potrzebujesz skompresowanego ładunku żądania w przepływie serwera proxy interfejsu API w Apigee Edge i na serwerze backendu, nie przekazuj nagłówka Content-Encoding. Jeśli musisz skompresować ładunek żądania, przejdź do kroku 2.
2. Sprawdź, czy 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 Apigee Edge pasuje do formatu kodowania określonego w nagłówku Content-Encoding
3. W omówionym powyżej przykładzie ładunek żądania jest w formacie ZIP, ale w nagłówku żądania występuje element Content-Encoding: gzip. Aby rozwiązać ten problem, wyślij nagłówek żądania jako Content-Encoding: gzip, a ładunek żądania także w formacie gzip:

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

Specyfikacja

Apigee Edge w odpowiedzi przesyła kod stanu 400 Bad Request z kodem błędu messaging.adaptors.http.flow.DecompressionFailureAtRequest zgodnie z tą specyfikacją RFC:

Specyfikacja
RFC 7231, sekcja 6.5.1
RFC 7231, sekcja 3.1.2.2

Jeśli nadal będziesz potrzebować pomocy zespołu pomocy Apigee, przejdź do artykułu Musisz zebrać informacje diagnostyczne.

Musisz zebrać informacje diagnostyczne

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

Jeśli jesteś użytkownikiem chmury publicznej, 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ń interfejsu API

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

• Zaobserwowany pełny komunikat o błędzie dotyczący nieudanych żądań
• Nazwa środowiska
• Pakiet proxy API
• Plik śledzenia żądań 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 wiadomości /opt/apigee/var/log/edge-message-processor/logs/system.log