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

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

Oprócz tego może pojawić się ten 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 żądania 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 przekracza dozwolony limit Rozmiar ładunku wysyłany przez aplikację kliencką w ramach żądania HTTP do Apigee Edge przekracza dozwolony limit w Apigee Edge. Użytkownicy chmury publicznej i prywatnej usługi Edge
Rozmiar ładunku żądania przekracza dozwolony limit po dekompresji Rozmiar ładunku wysyłany w formacie skompresowanym przez aplikację kliencką w ramach żądania HTTP do Apigee Edge przekracza dozwolony limit po zdekompresowaniu przez Apigee Edge. 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:

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 interfejsów API > Zbadaj.
  4. Wybierz przedział czasu, w którym zaobserwowano błędy.
  5. Możesz wybrać filtr Serwer proxy, aby zawęzić liczbę kodów błędów.
  6. Porównaj kod błędu z czasem.

  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 jak poniżej:

  9. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania. Następnie w oknie Logi zapoznaj się ze szczegółami podanymi poniżej :

    Nieskompresowany

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

    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 (~15 MB)

    Jeśli źródło błędu ma wartość proxy, kod błędu ma wartość protocol.http.TooBigBody, a długość żądania jest większa niż 10 MB, oznacza to, że żądanie HTTP od klienta ma ładunek żą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 (~15 kB)

    Jeśli źródło błędu ma wartość proxy, kod błędu ma wartość protocol.http.TooBigBody, a długość żądania jest mniejsza niż 10 MB, oznacza to, że rozmiar ładunku żądania HTTP od klienta w formacie skompresowanym jest mniejszy niż dozwolony limit, ale rozmiar ładunku przekracza dozwolony limit po zdekompresowaniu przez Apigee.

Trace

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

  1. Włącz sesję śledzenia i
    • Poczekaj na wystąpienie błędu 413 Request Entity Too Large lub
    • Jeśli możesz odtworzyć problem, wykonaj wywołanie interfejsu API i odtwórz błąd 413 Request Entity Too Large

  2. Upewnij się, że opcja Pokaż wszystkie informacje o przepływie jest włączona.

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

    Nieskompresowany

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

    Uwaga:

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

    Skompresowany

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

    Uwaga:

    • Kodowanie treści: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.

  6. Błąd pojawia się zwykle w procesie po fazie Żądanie otrzymane od klienta, jak pokazano poniżej:

  7. Zapisz wartość błędu ze śledzenia. Powyższy przykładowy log czasu pokazuje:
    • błąd: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. Otwórz Odpowiedź wysłana do klienta i zanotuj wartości błędu z logu czasu. Przykładowy ślad poniżej pokazuje:

    • 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 (rejestrowane dane Analytics) w śledzeniu i kliknij ją.

  10. W sekcji Szczegóły fazy przewiń w dół do opcji Odczyt zmiennych.

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

    Nieskompresowany

    Scenariusz 1. Żądanie ładunku w nieskompresowanej formie

    zmienna client.received.content.length: 15360204

    Skompresowany

    Scenariusz 2. Żądanie ładunku w formacie skompresowanym

    zmienna client.received.content.length: 10489856

  12. W tabeli poniżej wyjaśniono, dlaczego Apigee zwraca błąd 413 w tych 2 scenariuszach, na podstawie wartości zmiennej klienta.received.content.length:
    Scenariusz Wartość client.received.content.length Przyczyna niepowodzenia
    Ładunek żądania w formacie nieskompresowanym Około 15 MB Rozmiar > dozwolony limit, który wynosi 10 MB.
    Ładunek żądania w formacie skompresowanym Około 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żywać logów dostępu NGINX do określania kluczowych informacji o błędach HTTP 413.

  2. Sprawdź logi dostępu do NGINX:

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

  3. Sprawdź, czy występują jakieś błędy 413 w danym okresie (jeśli problem występował w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 413.
  4. Jeśli znajdziesz błędy 413 z kodem X-Apigee-fault-code pasującym do wartości X-Apigee-fault-code , sprawdź wartość źródła błędów X-Apigee-fault-code .

    Nieskompresowany

    Scenariusz 1. Żądany rozmiar ładunku w formacie nieskompresowanym

    Powyższy przykładowy wpis z logu dostępu NGINX ma następujące wartości kodów 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. Żądaj rozmiaru ładunku w formacie skompresowanym

    Powyższy przykładowy wpis z logu dostępu NGINX ma następujące wartości kodu 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 413, mimo że długość żądania jest mniejsza niż dozwolony limit, ponieważ żądanie mogło zostać wysłane w formacie skompresowanym, a rozmiar ładunku przekracza limit po dekompresji przez Apigee Edge.

Przyczyna: rozmiar ładunku żądania jest większy niż dozwolony limit

Diagnostyka

  1. Określ kod błędu, źródło błędu i rozmiar ładunku żądania dla błędu zaobserwowanego przy użyciu logów dostępu API Monitoring, narzędzia do śledzenia lub NGINX zgodnie z częstymi krokami diagnostycznymi dla scenariusza nr 1 (bez kompresji).
  2. Jeśli źródło błędu 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 z kroku 1.
  4. Możesz też sprawdzić, czy rozmiar ładunku żądania przekracza 10 MB dozwolony limit, sprawdzając żądanie, wykonując te czynności:
    1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego przez aplikację kliencką, przejdź do sekcji Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację kliencką, 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 przyczyną problemu.

        3. Przykładowe żądanie:

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

        W tym przypadku rozmiar pliku test15mbfile to około 15 MB. Jeśli korzystasz z innego klienta, pobierz logi klienta, aby sprawdzić rozmiar wysyłanego ładunku.

Rozdzielczość

Kliknij Rozwiązanie.

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

Jeśli ładunek żądania jest wysyłany w formacie skompresowanym, a nagłówek żądania Content-Encoding jest ustawiony na gzip, Apigee dekompresuje ładunek żądania. Jeśli w trakcie procesu dekompresji Apigee ustali, że rozmiar ładunku przekracza 10 MB, jest dozwolony limit, zatrzymuje dalszą dekompresję i natychmiast odpowiada 413 Request Entity Too Large z kodem błędu protocol.http.TooBigBody.

Diagnostyka

  1. Określ kod błędu, źródło błędu i rozmiar ładunku żądania dla błędu zaobserwowanego w logach monitorowania interfejsu API, narzędzia śledzenia lub logu dostępu NGINX zgodnie z opisem w sekcji Typowe kroki diagnostyki dla scenariusza nr 2 (skompresowany).
  2. Jeśli źródło błędu 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 dozwolony rozmiar ładunku przekracza 10 MB, to jest przyczyną błędu.
    • Jeśli dozwolony rozmiar ładunku nie przekracza 10 MB, możliwe, że ładunek żądania jest przekazywany w formacie skompresowanym. W tym przypadku sprawdź nieskompresowany rozmiar ładunku skompresowanego żądania.
  4. Za pomocą jednej z tych metod możesz sprawdzić, czy żądanie od klienta zostało wysłane w formacie skompresowanym, a rozmiar nieskompresowany przekraczał dozwolony limit:

    Trace

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

    1. Jeśli masz zarejestrowany log czasu dla nieudanego żądania, zapoznaj się z krokami opisanymi w sekcjach Śledzenie i
      1. Określ wartość zmiennej client.received.content.length
      2. Sprawdź, czy żądanie klienta zawiera nagłówek Content-Encoding: gzip
    2. Jeśli wartość zmiennej client.received.content.length przekracza dozwolony limit, dozwolony limit i nagłówek żądania client.received.content.length , jest to przyczyną 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ę kliencką, przejdź do sekcji Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację kliencką, wykonaj te czynności:
      1. Sprawdź rozmiar ładunku przekazanego w żądaniu wraz z nagłówkiem Content-Encoding wysłanym w żądaniu.

      2. Sprawdź, czy rozmiar nieskompresowanego ł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 powyższym przypadku rozmiar pliku test15mbfile.gz jest mniejszy niż limit rozmiaru, jednak rozmiar nieskompresowanego pliku test15mbfile wynosi około 15 MB, a nagłówek Content-Encoding to gzip.

        Jeśli korzystasz z innego klienta, sprawdź logi klienta, aby sprawdzić rozmiar wysyłanego ładunku i sprawdzić, czy nagłówek Content-Encoding jest ustawiony na gzip.

    Logi procesora wiadomości

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

    1. 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 413.

    2. Sprawdź dzienniki procesora wiadomości:

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

    3. Sprawdź, czy występują jakieś błędy 413 w określonym czasie (jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 413.

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

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Zobaczysz wiersze ze źródła system.log podobne do tych (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. Gdy tylko w trakcie procesu dekompresji procesor wiadomości ustali, że łączna liczba odczytanych bajtów przekroczy 10 MB, zatrzymuje się i drukuje następujący wiersz:
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Wskazuje on, ż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ść

Stały rozmiar

Opcja nr 1 [zalecana]: napraw aplikację kliencką, aby nie wysyłała ładunku większego niż dozwolony limit

  1. Przeanalizuj, dlaczego określony klient wysłał żądanie lub ładunek większy niż dozwolony limit określony w sekcji Limity.

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

    W podanym wyżej przykładzie możesz rozwiązać problem, przesyłając ładunek test5mbfile (o rozmiarze 5 MB):

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

  3. Jeśli chcesz, aby Twoje żądanie lub ładunek było więcej niż dozwolony limit, przejdź do kolejnych opcji.

Wzorzec podpisanego adresu URL

Opcja 2 [zalecana]: użyj wzorca podpisanych adresów URL w objaśnieniu Java w Apigee

W przypadku ładunków większych niż 10 MB Apigee zaleca użycie wzorca podpisanego adresu URL w Apigee JavaCallout. Przedstawiliśmy to na przykładzie narzędzia Edge Callout: Signed URL Generator na GitHubie.

transmisje

Opcja 3. Korzystanie z transmisji

Jeśli serwer proxy interfejsu API musi obsługiwać bardzo duże żądania lub odpowiedzi, możesz włączyć strumieniowe przesyłanie danych 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żna korzystać z żadnej z zalecanych opcji, ponieważ po zwiększeniu rozmiaru domyślnego mogą wystąpić problemy z wydajnością.

Apigee udostępnia właściwość CwC, która umożliwia zwiększenie limitu ładunku żądań i odpowiedzi. Szczegółowe informacje znajdziesz w artykule o ustawianiu limitu rozmiaru wiadomości w routerze lub procesorze wiadomości.

Ograniczenia

Apigee oczekuje, że aplikacja kliencka i serwer backendu nie będą wysyłać ładunków większych niż dozwolony limit określony dla Request/response size w limitach Apigee Edge.

  1. Jeśli jesteś użytkownikiem chmury publicznej, maksymalny rozmiar ładunku żądań i odpowiedzi jest określony dla Request/response size w limitach Apigee Edge.
  2. Jeśli jesteś użytkownikiem Private Cloud , możesz zmienić domyślny limit rozmiaru ładunku żądań i odpowiedzi (chociaż nie jest to zalecane). Aby określić maksymalny rozmiar ładunku żądania, wykonaj instrukcje z artykułu Jak sprawdzić bieżący limit.

Jak sprawdzić aktualny limit?

Ta sekcja wyjaśnia, jak sprawdzić, czy właściwość HTTPRequest.body.buffer.limit została zaktualizowana o nową wartość w procesorach wiadomości.

  1. Na komputerze procesora 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 przy użyciu tego polecenia:
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Przykładowy wynik tego polecenia: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. W przykładowych danych wyjściowych powyżej można zauważyć, że właściwość HTTPRequest.body.buffer.limit została ustawiona z wartością 10m w kolumnie http.properties.

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

Jeśli nadal będziesz potrzebować pomocy zespołu pomocy Apigee, przejdź do artykułu Wymagane jest zbieranie informacji diagnostycznych.

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
  • Kompletne polecenie curl użyte do odtworzenia błędu 413
  • 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 organizacji
  • Nazwa środowiska
  • Pakiet proxy 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 rzeczywistymi wartościami.

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