Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

500 Wewnętrzny błąd serwera – strumieniowe przesyłanie danych włączone

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu odpowiedzi HTTP 500 z komunikatem Internal Server Error (Wewnętrzny błąd serwera) w przypadku wywołań interfejsu API.

Komunikaty o błędach

Aplikacje klienckie mogą otrzymywać odpowiedź o błędzie w sposób pokazany poniżej:

HTTP/1.1 500 Internal Server Error

Może się po niej pojawić komunikat o błędzie podobny do tego:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Możliwe przyczyny

Błąd 500 Internal Server Error może wystąpić z wielu różnych powodów. Ten przewodnik skupia się na błędzie 500 Internal Server Error spowodowanym dostępem do ładunku żądania/odpowiedzi , gdy włączone jest przesyłanie strumieniowe.

Przyczyna	Opis	Kto może wykonać czynności rozwiązywania problemów
Dostęp do ładunku z włączonym przesyłaniem strumieniowym	Wystąpił błąd, ponieważ uzyskano dostęp do ładunku żądania/odpowiedzi, gdy włączone było przesyłanie strumieniowe.	Użytkownicy chmury prywatnej i publicznej Edge

Przyczyna: dostęp do ładunku z włączonym przesyłaniem strumieniowym

Diagnostyka

Procedura 1. Używanie śledzenia

Włącz sesję śledzenia i wywołaj interfejs API, aby odtworzyć problem – błąd 500 Internal Server Error.
Wybierz jedno z żądań, które się nie powiodły, i sprawdź ślad.
Przejdź przez różne etapy śledzenia i znajdź miejsce, w którym wystąpił błąd.
Ten błąd mógł wystąpić, gdy zasada analizowała ładunek żądania/odpowiedzi.
Oto przykładowy zrzut ekranu śledzenia pokazujący, że zasada JSONThreatProtection nie działa z powodu błędu "Expecting } at line 1":

Zanotuj te informacje z danych wyjściowych śledzenia, jak pokazano na zrzucie ekranu powyżej:

Zasada, która nie działa: JSONThreatProtection

Automatyzacja: Żądanie serwera proxy

Sprawdź definicję zasady, która nie działa, i sprawdź analizowany ładunek.

W przykładowym scenariuszu sprawdź zasadę JSONThreatProtection o nazwie JSON-Threat-Protection , która nie działa, i sprawdź element <Source>.

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

Zwróć uwagę, że element <Source> wskazuje request.. Oznacza to, że błąd wystąpił podczas analizowania ładunku żądania.

Określ typ analizowanego ładunku, sprawdzając żądanie do interfejsu API.

Możesz sprawdzić zawartość ładunku żądania i Content-Type nagłówek w żądaniu do interfejsu API. W tym przykładzie polecenia curl używany jest ładunek JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Możesz też sprawdzić zasadę, która nie działa, i określić typ analizowanego ładunku. W przykładowym scenariuszu powyżej zasada JSON-Threat-Protection nie działa. Oznacza to, że ładunek musi być w formacie JSON.

Sprawdź, czy ładunek jest w prawidłowym formacie. Jeśli ładunek jest nieprawidłowy, może wystąpić ten błąd.

Uwaga: Jeśli ładunek jest duży, możesz użyć dowolnego formatowania online, aby sprawdzić jego format.
Jeśli ładunek jest prawidłowy, ale nadal występują błędy wymienione w sekcji Komunikaty o błędach, przyczyną tych błędów jest to, że uzyskiwany jest dostęp do ładunku, gdy włączone jest przesyłanie strumieniowe.

W zależności od ładunku analizowanego przez zasadę (jak określono w kroku 6), sprawdź zawartość ładunku w narzędziu do śledzenia w odpowiedniej fazie.

W przykładowym scenariuszu analizowany jest ładunek żądania, więc sprawdź fazę "Request Received from Client" (Żądanie odebrane od klienta) w śledzeniu i sprawdź Request Content (Zawartość żądania).

Jeśli zawartość żądania jest pusta, jak pokazano na zrzucie ekranu powyżej, mimo że wysłano prawidłowy ładunek, oznacza to, że prawdopodobną przyczyną tego problemu jest włączone przesyłanie strumieniowe żądań.

Dzieje się tak, ponieważ gdy włączone jest przesyłanie strumieniowe, ładunek żądania nie będzie widoczny w śledzeniu.

Podobnie, jeśli podczas wystąpienia błędu analizowany jest ładunek odpowiedzi, sprawdź zawartość odpowiedzi w fazie „Response received from target server” (Odpowiedź odebrana z serwera docelowego).
Następnie sprawdź definicje proxy i docelowego punktu końcowego w zależności od tego, gdzie w automatyzacji proxy interfejsu API używana jest zasada, która nie działa. Sprawdź, czy przesyłanie strumieniowe jest włączone.

W przykładowym scenariuszu zasada, która nie działa, została wykonana w automatyzacji żądania serwera proxy (jak określono w kroku 5 powyżej). Dlatego sprawdź punkt końcowy serwera proxy:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
Jak widać w powyższym przykładzie, przesyłanie strumieniowe żądań zostało włączone, co wskazuje właściwość "request.streaming.enabled" ustawiona na true.

Przyczyną błędu jest więc użycie zasady JSONThreatProtection w proxy interfejsu API która uzyskuje dostęp do ładunku żądania, gdy włączone jest przesyłanie strumieniowe. Powoduje to błędy, ponieważ to wywołuje buforowanie w proxy interfejsu API i niweczy cel używania przesyłania strumieniowego w Apigee Edge.

Ten błąd może nie występować w przypadku mniejszych ładunków, ale gdy używasz większych ładunków, możesz zobaczyć te błędy.
Aby sprawdzić, czy błąd 500 jest spowodowany zasadą, sprawdź wartość "X-Apigee-fault-source" w fazie „AX” (Analytics Data Recorded) w śledzeniu, wykonując te czynności:
1. Kliknij fazę "AX" (Zarejestrowane dane analityczne) jak pokazano na zrzucie ekranu poniżej:
2. Przewiń w dół szczegóły fazy do sekcji „Error Headers” i określ wartości „X-Apigee-fault-code”, „X-Apigee-fault-source” i „X-Apigee-fault-policy”, jak pokazano poniżej:
3. Jeśli wartość „X-Apigee-fault-source” to „policy” jak pokazano na obrazie powyżej, oznacza to, że błąd jest spowodowany zasadą, która uzyskuje dostęp do ładunku, gdy włączone jest przesyłanie strumieniowe.

Rozdzielczość

Dostęp do ładunku z włączonym przesyłaniem strumieniowym jest antypatternem, jak wyjaśniono w Antypattern: dostęp do ładunku żądania/odpowiedzi, gdy włączone jest przesyłanie strumieniowe.

Jeśli chcesz przetworzyć ładunek, musisz wyłączyć przesyłanie strumieniowe w punkcie końcowym serwera proxy lub docelowym , usuwając właściwości "request.streaming.enabled" and "response.streaming.enabled"jak pokazano w przykładzie ProxyEndpoint poniżej:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
LUB
Jeśli chcesz używać przesyłania strumieniowego w przypadku proxy interfejsu API, nie używaj w proxy interfejsu API żadnych zasad, które uzyskują dostęp do ładunku żądania/odpowiedzi.

Uwaga:

W tym przewodniku w przykładowym scenariuszu użyto zasady JSONThreatProtection do przetwarzania ładunku żądania z włączonym przesyłaniem strumieniowym. Spowodowało to błąd 500 Internal Server Error z różnymi błędami.
Te błędy mogą też występować w przypadku zasad takich jak JSONToXML i XMLToJSON, które przetwarzają ładunki żądań lub odpowiedzi, gdy włączone jest przesyłanie strumieniowe.
Zdecydowanie zalecamy, aby nie używać takich zasad w proxy, które wymagają dostępu do ładunków, gdy włączone jest przesyłanie strumieniowe.
Jest to antypattern, jak opisano w Antypattern: dostęp do ładunku żądania/odpowiedzi, gdy włączone jest przesyłanie strumieniowe.

Diagnozowanie problemów za pomocą monitorowania interfejsu API

Jeśli korzystasz z chmury prywatnej, pomiń tę procedurę.

Monitorowanie interfejsu API umożliwia szybkie izolowanie obszarów problemowych w celu diagnozowania błędów, problemów z wydajnością i opóźnieniami oraz ich źródła, takiego jak aplikacje deweloperów, proxy interfejsu API, cele backendu lub platforma interfejsu API.

Wykonaj przykładowy scenariusz, który pokazuje, jak rozwiązywać problemy z kodami 5xx w interfejsach API za pomocą monitorowania interfejsu API. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba błędów 500 przekroczy określony próg.

Jeśli chcesz otrzymywać powiadomienia, gdy zasada zwraca błąd 500, musisz skonfigurować alert dla kodu stanu 500 ze źródłem błędu ustawionym na Proxy.

Informacje diagnostyczne, które musisz zebrać

Jeśli problem nadal występuje nawet po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee i udostępnij mu te informacje.

Jeśli korzystasz z chmury publicznej, podaj te informacje:

Nazwa organizacji
Nazwa środowiska
Nazwa proxy interfejsu API
Pełne polecenie curl wraz z ładunkiem żądania (jeśli występuje), aby odtworzyć błąd 500
Plik śledzenia zawierający żądania z błędem 500 Internal Server Error
Jeśli błędy 500 nie występują obecnie, podaj okres z informacjami o strefie czasowej, w którym błędy 500 występowały w przeszłości.

Jeśli korzystasz z chmury prywatnej, podaj te informacje:

Pełny komunikat o błędzie zaobserwowany w przypadku żądań, które się nie powiodły
Nazwa organizacji, środowiska i proxy interfejsu API, w przypadku których występują błędy 500
Pakiet proxy interfejsu API
Ładunek użyty w żądaniu (jeśli występuje)
Plik śledzenia zawierający żądania z błędem 500 Internal Server Error
Dzienniki dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Dzienniki procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Okres z informacjami o strefie czasowej, w którym wystąpiły błędy 500.