413 Jednostka żądania jest za duża – TooBigBody

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 413 Request Entity Too Large z kodem błędu protocol.http.TooBigBody .

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi: 

HTTP/1.1 413 Request Entity Too Large

Możesz też zobaczyć ten komunikat o błędzie: 

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Możliwe przyczyny

Ten błąd występuje, gdy rozmiar ładunku wysłanego przez aplikację kliencką do Apigee Edge w ramach żądania HTTP jest większy niż dozwolony limit w Apigee Edge .

Oto możliwe przyczyny tego błędu :

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Rozmiar ładunku żądania przekracza dopuszczalny limit Rozmiar ładunku wysłanego przez aplikację kliencką w ramach żądania HTTP do Apigee Edge przekracza dozwolony limit w Apigee Edge. Użytkownicy publicznej i prywatnej chmury Edge
Rozmiar ładunku żądania po dekompresji przekracza dopuszczalny limit Rozmiar ładunku wysłanego w formacie skompresowanym przez aplikację kliencką w ramach żądania HTTP do Apigee Edge przekracza dozwolony limit po dekompresji przez Apigee Edge. Użytkownicy publicznej i prywatnej chmury Edge

Typowe etapy diagnostyki

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

Monitorowanie interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsu API:

  1. Zaloguj się w interfejsie Apigee Edge jako użytkownik z  odpowiednią rolą.

  2. Przełącz się na organizację, w której chcesz zbadać problem.

  3. Otwórz stronę Analiza > Monitorowanie interfejsu API > Zbadaj.
  4. Wybierz konkretny przedział czasowy, w którym wystąpiły błędy.
  5. Aby zawęzić zakres kodu błędu, możesz wybrać filtr Proxy.
  6. Wykreśl kod błędu na osi czasu.

  7. Wybierz komórkę z kodem błędu protocol.http.TooBigBody i kodem stanu 413, jak pokazano poniżej:

  8. Informacje o kodzie błędu protocol.http.TooBigBody są wyświetlane w sposób pokazany poniżej:

  9. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania. Następnie w oknie Logi zanotuj szczegóły widoczne poniżej :

    Nieskompresowany

    Scenariusz 1. Ładunek żądania wysłany w formie nieskompresowanej

    W oknie Dzienniki zwróć uwagę na te informacje:

    • Kod stanu: 413
    • Źródło błędu: proxy
    • Kod błędu: protocol.http.TooBigBody.
    • Długość żądania(w bajtach): 15360440 (~15 MB)

    Jeśli Fault Source ma wartość proxy, Fault Code ma wartość protocol.http.TooBigBody, a Request Length przekracza 10 MB, oznacza to, że żądanie HTTP od klienta ma rozmiar ładunku większy niż dozwolony limit w Apigee.

    Skompresowano

    Scenariusz 2. Treść żądania wysłana w formie skompresowanej

    W oknie Dzienniki zwróć uwagę na te informacje:

    • Kod stanu: 413
    • Źródło błędu: proxy
    • Kod błędu: protocol.http.TooBigBody.
    • Długość żądania(w bajtach): 15264 (~15 KB)

    Jeśli Fault Source ma wartość proxy, Fault Code ma wartość protocol.http.TooBigBody, a Request Length jest mniejsza niż 10 MB, oznacza to, że żądanie HTTP od klienta ma rozmiar ładunku mniejszy niż dozwolony limit w formacie skompresowanym, ale rozmiar ładunku jest większy niż dozwolony limit po rozpakowaniu przez Apigee.

Śledzenie

Aby zdiagnozować błąd za pomocą narzędzia Trace:

  1. Włącz śledzenie sesji i wybierz jedną z tych opcji:
    • Poczekaj na wystąpienie błędu 413 Request Entity Too Large lub
    • Jeśli możesz odtworzyć problem, wywołaj interfejs API i odtwórz 413 Request Entity Too Large błąd.

  2. Sprawdź, czy opcja Show all Flow Infos (Pokaż wszystkie informacje o przepływie) jest włączona.

  3. Wybierz jedno z nieudanych żądań i sprawdź ślad.
  4. Przejdź do etapu Prośba otrzymana od klienta.

    Nieskompresowany

    Scenariusz 1. Ładunek żądania wysłany w formie nieskompresowanej

    Pamiętaj:

    • Content-Encoding: brak
    • Content-Length: 15360204

    Skompresowano

    Scenariusz 2. Treść żądania wysłana w formie skompresowanej

    Pamiętaj:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. Przeglądaj różne fazy śledzenia i sprawdź, gdzie wystąpił błąd.

  6. Błąd zwykle występuje w przepływie po fazie Request Received from Client (Otrzymano prośbę od klienta), jak pokazano poniżej:

  7. Zanotuj wartość błędu z trace’u. Powyższy przykładowy log czasu pokazuje:
    • Błąd: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. Otwórz sekcję Response Sent to Client (Odpowiedź wysłana do klienta) i zanotuj wartości błędu z informacji o śledzeniu. Przykładowy log czasu poniżej pokazuje:

    • Błąd: 413 Request Entity Too Large
    • Treść błędu: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. W śladzie przejdź do fazy AX (Analytics Data Recorded) i kliknij ją.

  10. W sekcji Szczegóły fazy przewiń w dół do Odczytane zmienne.

  11. Określ wartość zmiennej client.received.content.length , która wskazuje:
    • rzeczywisty rozmiar ładunku żądania, gdy jest on wysyłany w formacie nieskompresowanym;
    • Rozmiar ładunku żądania po dekompresji przez Apigee, gdy ładunek jest wysyłany w skompresowanym formacie. W tym przypadku będzie ona zawsze taka sama jak wartość dozwolonego limitu (10 MB).

    Nieskompresowany

    Scenariusz 1. Prośba o ładunek w formie nieskompresowanej

    Zmienna client.received.content.length: 15360204

    Skompresowano

    Scenariusz 2. Treść żądania w skompresowanym formacie

    Zmienna client.received.content.length: 10489856

  12. W tabeli poniżej wyjaśniamy, dlaczego Apigee zwraca błąd 413 w 2 scenariuszach na podstawie wartości zmiennej client.received.content.length:
    Scenariusz Wartość parametru client.received.content.length Przyczyna niepowodzenia
    Ładunek żądania w formacie nieskompresowanym ~15 MB Rozmiar > dozwolony limit 10 MB.
    Ładunek żądania w skompresowanym formacie ~10 MB

    Przekroczono limit rozmiaru po rozpakowaniu

NGINX

Aby zdiagnozować błąd za pomocą dzienników dostępu NGINX:

  1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz używać dzienników dostępu NGINX do określania kluczowych informacji o błędach HTTP 413.

  2. Sprawdź logi dostępu NGINX:

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

  3. Sprawdź, czy w określonym czasie (jeśli problem wystąpił w przeszłości) nie wystąpiły żadne 413błędy lub czy nadal występują błędy w przypadku niektórych żądań413.
  4. Jeśli znajdziesz błędy 413, w których X-Apigee-fault-code pasuje do wartości protocol.http.TooBigBody, określ wartość X-Apigee-fault-source.

    Nieskompresowany

    Scenariusz 1. Rozmiar ładunku żądania w formacie nieskompresowanym

    Powyższy przykładowy wpis z dziennika dostępu NGINX zawiera te wartości w przypadku X-Apigee-fault-code i X-Apigee-fault-source:

    Nagłówki odpowiedzi Wartość
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Zwróć uwagę na Długość żądania: 15360440 (14,6 MB > dozwolony limit).

    Skompresowano

    Scenariusz 2. Rozmiar ładunku żądania w formacie skompresowanym

    Powyższy przykładowy wpis z dziennika dostępu NGINX zawiera te wartości atrybutów X-Apigee-fault-code i X-Apigee-fault-source:

    Nagłówki odpowiedzi Wartość
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    Zwróć uwagę na długość żądania: 15264 (14,9 K < dozwolony limit).

    W takim przypadku Apigee Edge zwraca 413, mimo że długość żądania jest mniejsza niż dopuszczalny limit, ponieważ żądanie mogło zostać wysłane w formacie skompresowanym, a rozmiar ładunku po dekompresji przez Apigee Edge przekracza limit.

Przyczyna: rozmiar ładunku żądania przekracza dozwolony limit

Diagnostyka

  1. Określ kod błędu, źródło błędu i rozmiar ładunku żądania w przypadku błędu zaobserwowanego przy użyciu monitorowania interfejsu API, narzędzia do śledzenia lub dzienników dostępu NGINX, zgodnie z opisem w typowych krokach diagnostycznych w scenariuszu 1 (nieskompresowanym).
  2. Jeśli Fault Source ma wartość policy lub proxy, oznacza to, że rozmiar ładunku żądania wysłanego przez aplikację kliencką do Apigee jest większy niż dozwolony limit w Apigee Edge.
  3. Sprawdź rozmiar ładunku żądania określony w kroku 1.
  4. Możesz też sprawdzić, czy rozmiar ładunku żądania jest rzeczywiście większy niż dopuszczalny limit 10 MB, wykonując te czynności:
    1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego przez aplikację klienta, przejdź do sekcji Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację klienta, wykonaj te czynności:
      1. Sprawdź rozmiar ładunku przekazanego w żądaniu.
      2. Jeśli okaże się, że rozmiar ładunku przekracza dozwolony limit w Apigee Edge, to jest to przyczyną problemu.

        3. Przykładowe żądanie:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        W tym przypadku plik test15mbfile ma około 15 MB. Jeśli używasz innego klienta, sprawdź jego logi, aby dowiedzieć się, jaki jest rozmiar wysyłanego ładunku.

Rozdzielczość

Otwórz Rozdzielczość.

Przyczyna: rozmiar ładunku żądania po dekompresji przekracza dopuszczalny limit

Jeśli ładunek żądania jest wysyłany w skompresowanym formacie, a nagłówek żądania Content-Encoding jest ustawiony na gzip, , Apigee dekompresuje ładunek żądania. Jeśli podczas dekompresji Apigee stwierdzi, że rozmiar ładunku jest większy niż 10 MB, czyli przekracza dozwolony limit, zatrzyma dalszą dekompresję i natychmiast odpowie 413 Request Entity Too Large kodem błędu protocol.http.TooBigBody.

Diagnostyka

  1. Określ kod błędu, źródło błędu, i rozmiar ładunku żądania w przypadku 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 w scenariuszu 2 (skompresowanym).
  2. Jeśli Fault Source ma wartość policy lub proxy, oznacza to, że rozmiar ładunku żądania wysłanego przez aplikację kliencką do Apigee jest większy niż dozwolony limit w Apigee Edge.
  3. Sprawdź rozmiar ładunku żądania określony w kroku 1.
    • Jeśli rozmiar ładunku przekracza dozwolony limit 10 MB, to jest to przyczyną błędu.
    • Jeśli rozmiar ładunku jest mniejszy niż dozwolony limit 10 MB, możliwe jest, że ładunek żądania jest przekazywany w formacie skompresowanym. W takim przypadku sprawdź nieskompresowany rozmiar skompresowanego ładunku żądania.
  4. Możesz sprawdzić, czy żądanie od klienta zostało wysłane w formacie skompresowanym, a rozmiar nieskompresowany przekracza dopuszczalny limit, za pomocą jednej z tych metod:

    Śledzenie

    Aby przeprowadzić weryfikację za pomocą narzędzia Śledzenie:

    1. Jeśli masz log czasu nieudanego żądania, wykonaj czynności opisane w sekcjach Śledzenie i 
      1. Określ wartość zmiennej client.received.content.length .
      2. Sprawdź, czy żądanie od klienta zawierało nagłówek Content-Encoding:gzip .
    2. Jeśli wartość zmiennej client.received.content.length jest większa niż 10 MB, czyli dozwolony limit, a nagłówek żądania Content-Encoding: gzip, to jest to przyczyna tego błędu.

    Rzeczywista prośba

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

    1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego przez aplikację klienta, przejdź do sekcji Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację klienta, wykonaj te czynności:
      1. Sprawdź rozmiar ładunku przekazanego w żądaniu wraz z nagłówkiem Content-Encoding wysłanym w żądaniu.

      2. Sprawdź, czy nieskompresowany rozmiar ładunku przekracza dozwolony limit w Apigee Edge.

        Przykładowe żądanie:

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        W tym przypadku plik test15mbfile.gz jest mniejszy niż limit rozmiaru, ale rozmiar nieskompresowanego pliku test15mbfile wynosi około 15 MB, a nagłówek Content-Encoding ma rozmiar gzip.

        Jeśli używasz innego klienta, pobierz jego logi, aby sprawdzić rozmiar ładunku wysyłanego przez klienta i czy nagłówek Content-Encoding jest ustawiony na gzip.

    Dzienniki procesora komunikatów

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

    1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz używać dzienników procesora komunikatów, aby określać kluczowe informacje o błędach HTTP 413.

    2. Sprawdź logi procesora komunikatów:

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

    3. Sprawdź, czy w określonym czasie wystąpiły jakieś błędy 413 (jeśli problem pojawił się w przeszłości) lub czy nadal występują błędy 413.

      Możesz użyć tych ciągów wyszukiwania:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Znajdziesz wiersze z system.log podobne do tych poniżej (TotalRead i chunkCount mogą się różnić w Twoim przypadku): 
      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
    5. Podczas dekompresji, gdy tylko procesor wiadomości stwierdzi, że łączna liczba odczytanych bajtów jest większa niż 10 MB, zatrzymuje się i wyświetla ten wiersz: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Oznacza to, że rozmiar ładunku żądania przekracza 10 MB, a Apigee zgłasza błąd RequestTooLarge, gdy rozmiar zaczyna przekraczać limit 10 MB, z kodem błędu protocol.http.TooBigBody.

Rozdzielczość

Ustalanie rozmiaru

Opcja 1. [Zalecana]: popraw aplikację klienta, aby nie wysyłała ładunków o rozmiarze większym niż dozwolony limit.

  1. Przeanalizuj powód, dla którego konkretny klient wysyła żądanie lub ładunek o rozmiarze większym niż dopuszczalny limit określony w sekcji Limity.

  2. Jeśli nie jest to pożądane, zmodyfikuj aplikację klienta, aby wysyłała żądania lub ładunki o rozmiarze mniejszym niż dopuszczalny limit.

    W omówionym powyżej przykładzie możesz rozwiązać problem, przekazując mniejszy plik, np. test5mbfile (o rozmiarze 5 MB), jak pokazano poniżej: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. Jeśli chcesz wysłać prośbę lub ładunek przekraczający dopuszczalny limit, przejdź do następnych opcji.

Wzorzec podpisanego adresu URL

Opcja 2 [zalecana]: użyj wzorca podpisanych adresów URL w ramach wywołania JavaCallout w Apigee

W przypadku ładunków większych niż 10 MB Apigee zaleca używanie wzorca podpisanych adresów URL w ramach wywołania JavaCallout w Apigee. Ilustruje to przykład Edge Callout: Signed URL Generator na GitHubie.

Streaming

Opcja 3. Użyj streamingu

Jeśli serwer proxy interfejsu API musi obsługiwać bardzo duże żądania lub odpowiedzi, możesz włączyć strumieniowanie w Apigee.

CwC

Opcja 4. Użyj usługi CwC, aby zwiększyć limit bufora

Tej opcji należy używać tylko wtedy, gdy nie możesz skorzystać z żadnej z zalecanych opcji, ponieważ zwiększenie domyślnego rozmiaru może spowodować problemy z wydajnością.

Apigee udostępnia właściwość CwC, która pozwala zwiększyć limit rozmiaru ładunku żądania i odpowiedzi. Szczegółowe informacje znajdziesz w artykule Ustawianie limitu rozmiaru wiadomości na routerze lub procesorze wiadomości.

Limity

Apigee oczekuje, że aplikacja kliencka i serwer backendu nie będą wysyłać ładunków o rozmiarach większych niż dozwolony limit, zgodnie z dokumentacją dotyczącą Request/response size w sekcji Limity Apigee Edge.

  1. Jeśli jesteś użytkownikiem chmury publicznej, maksymalny limit rozmiaru ładunku żądania i odpowiedzi jest taki, jak podano w przypadku Request/response size w sekcji Limity Apigee Edge.
  2. Jeśli jesteś użytkownikiem chmury prywatnej , możesz mieć zmodyfikowany domyślny limit rozmiaru ładunku żądania i odpowiedzi (chociaż nie jest to zalecane). Maksymalny limit rozmiaru ładunku żądania możesz określić, postępując zgodnie z instrukcjami w artykule Jak sprawdzić obecny limit.

Jak sprawdzić bieżący limit?

W tej sekcji dowiesz się, jak sprawdzić, czy w procesorach wiadomości usługa HTTPRequest.body.buffer.limit została zaktualizowana o nową wartość.

  1. Na komputerze procesora komunikatów wyszukaj właściwość HTTPRequest.body.buffer.limit w katalogu /opt/apigee/edge-message- processor/conf i sprawdź, jaka wartość została ustawiona za pomocą tego polecenia: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Przykładowy wynik powyższego polecenia wygląda tak: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. W przykładzie danych wyjściowych powyżej zwróć uwagę, że właściwość HTTPRequest.body.buffer.limit ma wartość 10m w http.properties.

    Oznacza to, że limit rozmiaru ładunku żądania skonfigurowany w Apigee w przypadku Private Cloud wynosi 10 MB.

Jeśli nadal potrzebujesz pomocy zespołu 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 413
  • 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 organizacji
  • Nazwa środowiska
  • Pakiet proxy interfejsu API
  • Plik śledzenia nieudanych żądań do interfejsu API
  • Pełne polecenie curl użyte do odtworzenia błędu 413

  • 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