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

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 413 Request Entity Too Large z kodem błędu protocol.http.TooBigBody w odpowiedzi na wywołania interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi: 

HTTP/1.1 413 Request Entity Too Large

Możesz też zobaczyć następujący komunikat o błędzie: 

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

Możliwe przyczyny

Ten błąd występuje, jeśli rozmiar ładunku wysyłany przez aplikację kliencką do Apigee Edge w ramach Żądanie HTTP przekracza dozwolony limit w Apigee Edge .

Oto możliwe przyczyny tego błędu :

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Rozmiar ładunku żądania jest większy niż dozwolony limit Rozmiar ładunku wysyłany przez aplikację kliencką w ramach żądania HTTP do Apigee Edge wynosi przekracza dozwolony limit w Apigee Edge. Użytkownicy chmury publicznej i prywatnej Edge
Rozmiar ładunku żądania przekracza dozwolony limit po dekompresja Rozmiar ładunku wysłanego w formacie skompresowanym przez aplikację kliencką w ramach protokołu HTTP żądania do Apigee Edge przekraczają dozwolony limit podczas zdekompresowania przez Apigee Edge. Użytkownicy chmury publicznej i prywatnej Edge

Typowe kroki diagnostyki

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

Monitorowanie interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsów API:

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

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

  3. Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
  4. Wybierz okres, w którym zaobserwowano błędy.
  5. Aby zawęzić kod błędu, możesz wybrać filtr Serwer proxy.
  6. Porównaj Kod błędu z czasem.

  7. Wybierz komórkę, która zawiera kod błędu protocol.http.TooBigBody i Kod stanu 413jak poniżej:

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

  9. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania. Następnie z poziomu Logi zwróć uwagę na poniższe szczegóły :

    Nieskompresowany

    Scenariusz 1. Żądanie ładunku wysłane w formie nieskompresowanej

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

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

    Jeśli Źródło błędu ma wartość proxy , parametr Fault Code ma wartość protocol.http.TooBigBody i Długość żądania przekracza 10 MB, oznacza to, że żądanie HTTP od klienta zawiera rozmiar ładunku żądania większy niż dozwolony limit w Apigee.

    Skompresowany

    Scenariusz 2. Żądanie ładunku wysłane w formie skompresowanej

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

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

    Jeśli Źródło błędu ma wartość proxy , parametr Fault Code ma wartość protocol.http.TooBigBody, a Długość żądania to mniej niż 10 MB, oznacza to, że żądanie HTTP od klienta zawiera rozmiar ładunku żądania jest niższy niż dozwolony limit w formacie skompresowanym, ale rozmiar ładunku po zdekompresowaniu przez Apigee przekracza dozwolony limit.

Śledzenie

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

  1. Włącz sesję śledzenia i wykonaj jedną z tych czynności:
    • 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 te dane. 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ź log czasu.
  4. Przejdź do etapu Prośba otrzymana od klienta.

    Nieskompresowany

    Scenariusz 1. Żądanie ładunku wysłane w formie nieskompresowanej

    Uwaga:

    • Content-Encoding: brak
    • Długość treści: 15360204

    Skompresowany

    Scenariusz 2. Żądanie ładunku wysłane w formie skompresowanej

    Uwaga:

    • Kodowanie treści: gzip
    • Długość treści: 14969
    • Typ treści: application/x-gzip
  5. Przejdź przez różne fazy śledzenia i znajdź miejsca, w których wystąpił błąd.

  6. Błąd występuje zwykle w ramach procesu po żądaniu otrzymania od Faza klienta, jak pokazano poniżej:

  7. Zwróć uwagę na wartość błędu z śladu. Powyższy przykładowy log czasu pokazuje:
    • błąd: Body buffer overflow
    • error.class::com.apigee.errors.http.user.RequestTooLarge

  8. Przejdź do obszaru Response Sent to Client (Odpowiedź wysłana do klienta) i zanotuj wartości błędu z parametru śledzić. Oto przykładowy log czasu:

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

  10. W sekcji Szczegóły etapu przewiń w dół do pozycji Odczyt zmiennych.

  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 to wysyłane w formacie skompresowanym. Będzie ona zawsze taka sama jak wartość dozwolonych (10 MB) w tym scenariuszu.
    .

    Nieskompresowany

    Scenariusz 1. Żądanie ładunku w formie nieskompresowanej

    Zmienna klienta.received.content.length: 15360204

    Skompresowany

    Scenariusz 2. Żądanie ładunku w formacie skompresowanym

    Zmienna klienta.received.content.length: 10489856

  12. W tabeli poniżej wyjaśniamy, dlaczego Apigee zwraca błąd 413 w dwa scenariusze oparte na wartości client.received.content.length zmiennej:
    Scenariusz Wartość client.received.content.length Przyczyna niepowodzenia
    Żądanie ładunku w nieskompresowanym formacie Ok. 15 MB Rozmiar > dozwolony limit to 10 MB.
    Żądanie ładunku w formacie skompresowanym Ok. 10 MB

    Przekroczono limit rozmiaru podczas dekompresji

NGINX

Aby zdiagnozować błąd przy użyciu logów dostępu NGINX:

  1. Jeśli jesteś użytkownikiem Private Cloud, możesz użyć logów dostępu NGINX, aby określić Kluczowe informacje o błędach HTTP 413.

  2. Sprawdź logi dostępu NGINX:

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

  3. Wyszukaj błędy (413) w tym okresie (jeśli wystąpił problem w przeszłości) lub jeśli jakieś żądania nadal kończą się niepowodzeniem 413
  4. Jeśli znajdziesz błędy 413 w dopasowaniu X-Apigee-fault-code wartość protocol.http.TooBigBody, a następnie ustal wartość X-Apigee-fault-source.

    Nieskompresowany

    Scenariusz 1. Żądanie rozmiaru ładunku w formacie nieskompresowanym

    Powyższy przykładowy wpis logu dostępu NGINX zawiera następujące wartości dla X-Apigee-fault-code i X-Apigee-fault-code :

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

    Skompresowany

    Scenariusz 2. Żądanie rozmiaru ładunku w formacie skompresowanym

    Powyższy przykładowy wpis z logu dostępu NGINX zawiera następujące wartości dla: X-Apigee-fault-code i X-Apigee-fault-code

    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 KB < dozwolony limit)

    W tym scenariuszu Apigee Edge zwraca wartość 413, mimo że Długość żądania jest mniejsza niż dozwolony limit, ponieważ żądanie może zostały wysłane w formacie skompresowanym, a rozmiar ładunku przekracza podczas dekompresji w Apigee Edge.

Przyczyna: rozmiar ładunku żądania przekracza dozwolony limit

Diagnostyka

  1. Określ kod błędu, źródło błędu i rozmiar ładunku żądania dla zaobserwowany błąd przy użyciu monitorowania API, narzędzia Trace lub logów dostępu NGINX, jak wyjaśniono w artykule Typowe kroki diagnostyki w scenariuszu 1 (bez kompresji).
  2. Jeśli Źródło błędu ma wartość policy lub proxy, to wskazuje, ż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 to rzeczywiście Dozwolony limit 10 MB przez sprawdzając faktyczne żądanie, wykonując te czynności:
    1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego przez aplikację kliencką, otwórz Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację kliencką, wykonaj następujące kroki:
      1. Sprawdź rozmiar ładunku przekazywanego w żądaniu.
      2. Jeśli okaże się, że rozmiar ładunku jest większy niż dozwolony limit w Apigee Edge, to jest przyczyną problemu.

        3. Przykładowe żądanie:

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

        W tym przypadku rozmiar pliku test15mbfile wynosi ok. 15 MB. Jeśli korzystają z innego klienta, pobierz logi klienta, aby sprawdzić rozmiar wysyłanego ładunku.

Rozdzielczość

Kliknij Rozwiązanie.

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

Jeśli ładunek żądania jest wysyłany w formacie skompresowanym i nagłówek żądania Content-Encoding ma wartość gzip, Apigee dekompresuje żądanie ładunek. Jeśli podczas procesu dekompresji Apigee stwierdzi, że rozmiar ładunku jest większy powyżej 10 MB, do dozwolonego limitu, następnie zatrzymuje dalszą dekompresję i reaguje natychmiast z kodem błędu 413 Request Entity Too Large protocol.http.TooBigBody

Diagnostyka

  1. Określ kod błędu, źródło błędu i rozmiar ładunku żądania. dla błędu zaobserwowanego za pomocą usługi API Monitoring, narzędzia śledzenia lub logów dostępu NGINX, jak opisano w Typowe kroki diagnostyki w scenariuszu nr 2 (skompresowanym).
  2. Jeśli Źródło błędu ma wartość policy lub proxy, oznacza to, że rozmiar ładunku żądania wysyłany przez aplikację kliencką do Apigee jest większy niż dozwolony limit w Apigee Edge.
  3. Sprawdź Rozmiar ładunku żądania zgodnie z krokiem 1.
    • Jeśli rozmiar ładunku > Limit 10 MB, to jest przyczyną błędu.
    • Jeśli rozmiar ładunku < dozwolony limit wynosi 10 MB, wówczas żądanie może jest przekazywany w formacie skompresowanym. W takim przypadku sprawdź rozmiar pliku nieskompresowanego skompresowanego ładunku żądania.
  4. Możesz sprawdzić, czy żądanie od klienta zostało wysłane w formacie skompresowanym, a tag rozmiar nieskompresowany był większy niż dozwolony limit w przypadku jednego z tych elementów metody:

    Śledzenie

    Aby sprawdzić poprawność za pomocą narzędzia śledzenia:

    1. Jeśli masz zarejestrowany ślad dla nieudanego żądania, zapoznaj się z krokami opisanymi w Trace i
      1. Określ wartość zmiennej client.received.content.length .
      2. Sprawdź, czy żądanie od klienta zawierało kodowanie Content-Encoding: gzip nagłówek
    2. Jeśli wartość zmiennej client.received.content.length jest większa niż 10 MB, dozwolony limit oraz nagłówek żądania Content-Encoding: gzip, to jest przyczyną tego błędu.

    Rzeczywiste żądanie

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

    1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego przez aplikację kliencką, otwórz Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację kliencką, wykonaj następujące kroki:
      1. Sprawdź rozmiar ładunku przekazywanego w żądaniu wraz z Nagłówek Content-Encoding został wysłany w żądaniu.

      2. Sprawdź, czy rozmiar ładunku nieskompresowanego nie jest większy niż 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, jednak rozmiar nieskompresowanego pliku test15mbfile wynosi około 15 MB. nagłówek Content-Encoding to gzip.

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

    Logi procesora wiadomości

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

    1. Jeśli jesteś użytkownikiem Private Cloud, możesz za pomocą logów procesora wiadomości określić Kluczowe informacje o błędach HTTP 413.

    2. Sprawdź dzienniki procesora wiadomości:

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

    3. Wyszukaj błędy 413, aby sprawdzić, czy w danym okresie nie wystąpiły jakieś błędy (jeśli w przeszłości) lub jeśli jakieś żądania nadal kończą się niepowodzeniem (413).

      Możesz użyć następujących ciągów wyszukiwania:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Znajdziesz tam wiersze z domeny 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 procesu dekompresji, gdy tylko procesor wiadomości określi łączną wartość, odczyt bajtów to > 10 MB, zatrzymuje się i wydrukuje następujący wiersz: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Oznacza to, że rozmiar ładunku żądania wynosi więcej niż 10 MB, a Apigee przesyła błąd RequestTooLarge, gdy rozmiar zaczyna przekraczać limit 10 MB z kodem błędu: protocol.http.TooBigBody

Rozdzielczość

Popraw rozmiar

Opcja nr 1 [zalecana]: popraw aplikację kliencką, aby nie wysyłała ładunków większych niż dozwolony limit

  1. Przeanalizuj przyczynę, dla której dany klient wysłał żądanie lub ładunek o rozmiarze większym niż dozwolony zgodnie z opisem w sekcji Limity.

  2. Jeśli nie jest to pożądane, zmodyfikuj aplikację kliencką tak, aby wysyłała żądanie / ładunek rozmiar mniejszy niż dozwolony limit.

    W przykładzie powyżej możesz rozwiązać problem, przesyłając plik o mniejszym rozmiarze, powiedzmy test5mbfile (z rozmiarem 5 MB), jak w przykładzie poniżej: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v

  3. Jeśli jest to pożądane i chcesz wysłać żądania lub ładunek więcej niż dozwolony limit, otwórz kolejne opcje.

Wzorzec podpisanego adresu URL

Opcja nr 2 [zalecana]: użyj wzorca podpisanego adresu URL w Apigee JavaCallout

W przypadku ładunków większych niż 10 MB Apigee zaleca używanie wzorca podpisanego adresu URL w tagu Apigee JavaCallout, ilustrowane przez Przykład Edge Callout: Generator podpisanego adresu URL w GitHubie.

Streaming

Opcja 3. Korzystanie ze strumieniowania

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

CwC

Opcja 4. Użyj właściwości CwC, aby zwiększyć limit bufora

Tej opcji należy używać tylko wtedy, gdy nie możesz użyć żadnej z zalecanych opcji, ponieważ może to w przypadku zwiększenia rozmiaru domyślnego mogą stanowić problemy z wydajnością.

Apigee zapewnia Właściwość CwC, która umożliwia zwiększanie limit rozmiaru ładunków żądań i odpowiedzi. Więcej informacji: Ustaw limit rozmiaru wiadomości w 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 informacjami dla Request/response size w Limity Apigee Edge.

  1. Jeśli jesteś użytkownikiem Public Cloud, maksymalny limit żądań i odpowiedzi rozmiar ładunku jest taki sam jak w przypadku Request/response size w Limity Apigee Edge.
  2. Jeśli jesteś użytkownikiem Private Cloud , możliwe, że wartości domyślne zostały zmienione limitu rozmiaru ładunku żądań i odpowiedzi (mimo że nie jest to zalecana metoda). Maksymalny rozmiar ładunku żądania możesz określić, postępując zgodnie z instrukcjami w Jak sprawdzić aktualny limit

Jak sprawdzić obecny limit?

Z tej sekcji dowiesz się, jak sprawdzić, czy usługa HTTPRequest.body.buffer.limit .

  1. Na komputerze z procesorem wiadomości 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ą tych metod polecenie: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Przykładowy wynik powyższego polecenia jest taki: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. Zwróć uwagę, że w przykładowych danych wyjściowych powyżej Parametr HTTPRequest.body.buffer.limit został ustawiony na wartość 10m w http.properties

    Wskazuje, że limit rozmiaru ładunku żądania skonfigurowanego w Apigee dla prywatnych Chmura ma 10 MB.

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, wejdź na Konieczne jest zbieranie informacji diagnostycznych.

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
  • Kompletne polecenie curl użyte do odtworzenia błędu 413
  • 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 organizacji
  • Nazwa środowiska
  • Pakiet serwera proxy interfejsu API
  • Plik śledzenia nieudanych żądań do interfejsu API
  • Kompletne 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 przez wartości rzeczywiste.

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