500 – wewnętrzny błąd serwera – BadPath

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 500 Internal Server Error z kodem błędu protocol.http.BadPath w odpowiedzi na wywołania interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

Możliwe przyczyny

Ten błąd występuje, jeśli adres URL żądania serwera backendu, reprezentowany przez zmienną przepływu target.url, zawiera path , który zaczyna się od znaku zapytania (?) zamiast od ukośnika (/), co jest nieprawidłowe.

Zgodnie ze specyfikacjami RFC 3986, sekcja 3: Składniki składni i RFC 3986, sekcja 3.3: Ścieżka:

1. Składnia identyfikatora URI zawiera te komponenty:

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. Komponent path jest wymagany i MUSI zaczynać się od ukośnika (/).

Jeśli więc adres URL żądania serwera backendu zawiera komponent path zaczynający się od znaku zapytania (?), a nie od ukośnika (/), Apigee Edge odpowiada kodem 500 Internal Server Error i kodem błędu protocol.http.BadPath.

Przykład: jeśli target.url ma wartość https://www.mocktarget.apigee.net?json, wystąpi ten błąd, ponieważ path jest nieprawidłowy, ponieważ zaczyna się od znaku zapytania (?), a nie od ukośnika (/).

Typowe etapy diagnostyki

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

Przyczyna: adres URL serwera backendu (target.url) ma nieprawidłową ścieżkę

Diagnostyka

1. Określ kod błędu i źródło błędu dla 500 Internal Server Error za pomocą usługi API Monitoring, narzędzia Trace Tool lub dzienników dostępu NGINX zgodnie z opisem w artykule Typowe kroki diagnostyczne.
2. Jeśli Kod błędu ma wartość protocol.http.BadPath, a Źródło błędu ma wartość target, oznacza to, że adres URL serwera backendu ma nieprawidłową ścieżkę.

3. Adres URL serwera backendu jest reprezentowany przez zmienną przepływu target.url w Apigee Edge. Ten błąd zwykle występuje, gdy próbujesz dynamicznie zaktualizować adres URL serwera backendu (target.url) za pomocą dowolnych zasad (w przepływie proxy lub współdzielonym przepływie) w przepływie żądania docelowego, tak aby zawierał nieprawidłową ścieżkę.

4. Sprawdź, czy zmienna przepływu target.url ma nieprawidłową ścieżkę i źródło jej wartości, korzystając z jednej z tych metod:

   Śledzenie

   Korzystanie z narzędzia Trace

   Jeśli udało Ci się zarejestrować ślad tego błędu, wykonaj czynności opisane w sekcjach Korzystanie z narzędzia Trace i

   1. Sprawdź, czy target.url ma nieprawidłową ścieżkę, czyli czy zaczyna się od znaku zapytania (?) zamiast od ukośnika (/).

   2. Jeśli tak, znajdź zasadę, która zmodyfikowała lub zaktualizowała wartość target.url, tak aby zawierała nieprawidłową ścieżkę.

      Przykładowy ślad pokazujący, że zasada JavaScriptu zaktualizowała zmienną przepływu target.url

      
   3. W powyższym przykładowym śledzeniu widać, że zasada JavaScript zmodyfikowała lub zaktualizowała wartość target.url, tak aby zawierała nieprawidłową ścieżkę.
   4. Pamiętaj, że target.url ma te komponenty:
      • scheme: https
      • authority: mocktarget.apigee.net
      • path: ?json

      Ścieżka zaczyna się od znaku zapytania (?) zamiast ukośnika (/), dlatego jest nieprawidłowa.

   Logi

   Korzystanie z logów na serwerze logów

   1. Jeśli nie masz śladu tego błędu (problem występuje sporadycznie), sprawdź, czy informacje o wartości zmiennej przepływu target.url zostały zarejestrowane za pomocą zasad, takich jak MessageLogging lub ServiceCallout, na serwerze dziennika.
   2. Jeśli masz logi, przejrzyj je i 
      1. Sprawdź, czy target.url ma nieprawidłową ścieżkę.
      2. Sprawdź, czy możesz określić informacje o tym, które zasady zostały zmodyfikowane target.url, aby zawierać nieprawidłową ścieżkę.

   Proxy interfejsu API

   Sprawdzanie działającego nieprawidłowo serwera proxy interfejsu API

   Jeśli nie masz śladu ani logów tego błędu, sprawdź nieprawidłowy serwer proxy interfejsu API, aby określić, co zmodyfikowało lub zaktualizowało zmienną przepływu target.url, tak że zawiera ona nieprawidłową ścieżkę. Sprawdź, czy:

   • Zasady w serwerze proxy interfejsu API
   • Wszystkie przepływy współdzielone wywoływane z proxy

5. Dokładnie sprawdź konkretne zasady (np. AssignMessage lub JavaScript), które modyfikują lub aktualizują zmienną przepływu target.url, i ustal przyczynę aktualizacji target.url, która powoduje nieprawidłową ścieżkę.

   Oto kilka przykładów zasad, które nieprawidłowo aktualizują zmienną przepływu target.url, tak aby zawierała nieprawidłową ścieżkę, co powoduje ten błąd.

   Próbka 1

   Przykład 1. Aktualizowanie zmiennej target.url zasady JavaScript

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);

   W powyższym przykładzie zmienna przepływu target.url jest aktualizowana wartością https://mocktarget.apigee.net?json zawartą w innej zmiennej url..

   Wartość url składa się z tych elementów:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?json

   Ścieżka zaczyna się od znaku zapytania (?) zamiast od ukośnika (/), co jest nieprawidłowe. Dlatego Apigee Edge zwraca 500 Internal Server Error z kodem błędu protocol.http.BadPath.

   Próbka 2

   Przykład 2. Aktualizowanie zmiennej target.url w zasadach JavaScriptu na podstawie wartości w nagłówku żądania

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   W powyższym przykładzie zmienna przepływu target.url jest aktualizowana przez połączenie wartości https://mocktarget.apigee.net zawartej w zmiennej url i wartości innej zmiennej path, której wartość jest pobierana z request.header.Path..

   Jeśli masz dostęp do rzeczywistego żądania lub śladu, możesz sprawdzić rzeczywistą wartość przekazaną do funkcji request.header.Path.

   Przykładowe żądanie przesłane przez użytkownika

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   W tym przykładzie ścieżka nagłówka nie jest wysyłana w ramach żądania. Wartość zmiennej path w zasadach JavaScriptu to null.

   Przykłady:

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   Wartość target.url składa się z tych elementów:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?user

   Ścieżka zaczyna się od znaku zapytania (?) zamiast od ukośnika (/), co jest nieprawidłowe. Dlatego Apigee Edge zwraca wartość 500 Internal Server Error z kodem błędu protocol.http.BadPath.

   Próbka 3

   Przykład 3. Aktualizowanie zmiennej target.url w zasadach AssignMessage

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   Pamiętaj, że wartość url ma te komponenty:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?echo

   W tym przykładzie ścieżka zaczyna się od znaku zapytania (?), a nie od ukośnika (/), co jest nieprawidłowe. Dlatego Apigee Edge zwraca 500 Internal Server Error z kodem błędu protocol.http.BadPath.

Rozdzielczość

Zgodnie ze specyfikacją adresu URL RFC 3986, sekcja 3: Składniki składni komponent path jest wymagany i musi zawsze zaczynać się od znaku „/”. Aby rozwiązać ten problem, wykonaj te czynności:

1. Sprawdź, czy adres URL serwera backendu, reprezentowany przez zmienną przepływu target.url, zawsze ma prawidłową ścieżkę i zawsze zaczyna się od ukośnika (/).
   1. W niektórych przypadkach w ścieżce może nie być nazwy zasobu. Wtedy upewnij się, że ścieżka zawiera co najmniej ukośnik (/).
   2. Jeśli do określania wartości zmiennej przepływu używasz innych zmiennych target.url, upewnij się, że nie mają one nieprawidłowej ścieżki.
   3. Jeśli wykonujesz operacje na ciągach znaków, aby określić wartość zmiennej przepływutarget.url, upewnij się, że wynik tych operacji nie zawiera nieprawidłowej ścieżki.

2. W przykładach omówionych powyżej możesz rozwiązać ten problem w sposób opisany poniżej:

   Próbka 1

   Przykład 1. Aktualizowanie zmiennej target.url zasady JavaScript

   Aby rozwiązać ten problem, użyj ukośnika (/) zamiast znaku zapytania (?) w zmiennej url, jak pokazano poniżej:

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);

   Próbka 2

   Przykład 2. Aktualizowanie zmiennej target.url w zasadach JavaScriptu na podstawie wartości w nagłówku żądania

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Aby rozwiązać ten problem, upewnij się, że w ramach nagłówka żądania Path przekazujesz prawidłową ścieżkę, np. /user, jak pokazano poniżej:

   Przykładowe żądanie:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   Próbka 3

   Przykład 3. Aktualizacja zmiennej target.url w zasadzie AssignMessage

   Dodaj prawidłową ścieżkę w elemencie <Value> zasady AssignMessage. Oznacza to, że w elemencie <Value> musisz zastąpić znak zapytania (?) ukośnikiem prawym (/) i ustawić wartość https://mocktarget.apigee.net/echo, aby rozwiązać ten problem, jak pokazano poniżej:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   Specyfikacja

   Apigee Edge oczekuje, że path komponent w adresie URL serwera backendu MUSI zawsze zaczynać się od ukośnika (/) zgodnie z tymi specyfikacjami:

   Specyfikacja
   RFC 3986, sekcja 3: Składniki składni
   RFC 3986, sekcja 3.3: Ścieżka

   Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, zapoznaj się z sekcją Informacje diagnostyczne, które musisz zebrać.

   musi zbierać informacje diagnostyczne;

   Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne i 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
   • Polecenie curl użyte do odtworzenia 500 Internal Server Error z kodem błędu protocol.http.BadPath
   • 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 środowiska
   • pakiet proxy interfejsu API,
   • Plik śledzenia żądań do 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 komunikatów /opt/apigee/var/log/edge-message- processor/logs/system.log

   Odniesienia

   Zmienne przepływu – wartość docelowa