500 – wewnętrzny błąd serwera – pusta ścieżka

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.EmptyPath 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":"Request path cannot be empty",
      "detail":{
         "errorcode":"protocol.http.EmptyPath"
      }
   }
}

Możliwe przyczyny

Ten błąd występuje, jeśli adres URL żądania serwera backendu, reprezentowany przez zmienną przepływu target.url, zawiera pustą ścieżkę.

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 zawsze zawierać ukośnik (/), nawet jeśli ścieżka nie zawiera innych znaków.

Jeśli więc adres URL żądania serwera backendu nie zawiera w ogóle komponentu path, czyli nie ma nawet ukośnika (/), Apigee Edge odpowiada kodem błędu 500 Internal Server Errorprotocol.http.EmptyPath.

Przykład: jeśli target.url ma wartość https://www.mocktarget.apigee.net, wystąpi ten błąd, ponieważ komponent path jest pusty lub go brakuje.

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Adres URL serwera backendu (target.url) ma pustą ścieżkę Adres URL serwera backendu reprezentowany przez zmienną przepływu target.url ma pustą ścieżkę. 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

Procedura 1. Korzystanie z monitorowania interfejsu 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. Wykreśl kod błędu na osi czasu.

  6. Wybierz komórkę z kodem błędu protocol.http.EmptyPath, jak pokazano poniżej:

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

  8. Kliknij Wyświetl logi , aby rozwinąć wiersz nieudanego żądania.

  9. W oknie Dzienniki zanotuj te informacje:
    • Kod stanu: 500
    • Źródło błędu: target
    • Kod błędu: protocol.http.EmptyPath
  10. Jeśli Źródło błędu to target, a Kod błędu to protocol.http.EmptyPath, oznacza to, że adres URL serwera backendu ma pustą ścieżkę.

Śledzenie

Procedura 2. Używanie narzędzia Ś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 500 Internal Server Error lub
    • Jeśli możesz odtworzyć problem, wykonaj wywołanie interfejsu API, aby go odtworzyć.500 Internal Server Error
  2. Sprawdź, czy opcja Pokaż wszystkie informacje o przepływach jest włączona:

  3. Wybierz jedno z nieudanych żądań i sprawdź ślad.
  4. Przeglądaj różne fazy śledzenia i sprawdź, gdzie wystąpił błąd.
  5. Błąd zwykle występuje w procesie po fazie Target Request Flow Started , jak pokazano poniżej:

  6. Zanotuj wartość błędu z trace’u.

    Błąd: ścieżka żądania nie może być pusta

    Ponieważ błąd jest zgłaszany przez Apigee Edge po fazie Target Request Flow Started, oznacza to, że path w adresie URL serwera backendu jest pusty. Najprawdopodobniej zdarzy się to, jeśli zmienna przepływu target.url (reprezentująca adres URL serwera backendu) została zaktualizowana o pustą ścieżkę przez jedną z zasad w przepływie żądania.

  7. Sprawdź sekcję Variables Read and Assigned (Odczytane i przypisane zmienne) w każdym z przepływów wstecz, od punktu błędu do fazy Target Request Flow Started (Rozpoczęto przepływ żądania docelowego).
  8. Określ zasadę, w której zmienna przepływu target.url jest aktualizowana.

    Przykładowy ślad pokazujący, że zasady JavaScript zaktualizowały zmienną przepływu target.url:

    W przykładowym śledzeniu powyżej zwróć uwagę na wartość zmiennej przepływu target.url , która jest aktualizowana w zasadach JavaScript o nazwie SetTargetURL w ten sposób:

    target.url : https://mocktarget.apigee.net
  9. Pamiętaj, że target.url ma te komponenty:
    • scheme: https://mocktarget.apigee.net
    • path: empty
  10. Dlatego pojawia się błąd Request path cannot be empty.
  11. W śladzie przejdź do fazy AX (Analytics Data Recorded) i kliknij ją.
  12. Przewiń w dół do sekcji Szczegóły fazy – Nagłówki błędów i określ wartości X-Apigee-fault-code i X-Apigee-fault-source, jak pokazano poniżej:

  13. Wartości X-Apigee-fault-code i X-Apigee-fault-source będą odpowiednio równe protocol.http.EmptyPath i target , co oznacza, że ten błąd jest spowodowany tym, że adres URL serwera backendu ma pustą ścieżkę.
    Nagłówki odpowiedzi Wartość
    X-Apigee-fault-code protocol.http.EmptyPath
    X-Apigee-fault-source target

NGINX

Procedura 3. Korzystanie z logów dostępu 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 żądaniach HTTP 500 Internal Server Error.
  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 ma 500 błędów z kodem błędu protocol.http.EmptyPath lub czy nadal występują żądania, które kończą się niepowodzeniem z kodem 500.
  4. Jeśli znajdziesz błędy 500, w których X-Apigee-fault-code pasuje do wartości protocol.http.EmptyPath, określ wartość X-Apigee-fault-source.

    Przykładowy błąd 500 z dziennika dostępu NGINX:

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

    Nagłówki Wartość
    X-Apigee-fault-code protocol.http.EmptyPath
    X-Apigee-fault-source target

    Zwróć uwagę, że wartości X-Apigee-fault-code i X-Apigee-fault-source to odpowiednio protocol.http.EmptyPath i target , co oznacza, że ten błąd jest spowodowany tym, że adres URL serwera backendu ma pustą ścieżkę.

Przyczyna: adres URL serwera backendu (target.url) ma pustą ś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 Fault Code ma wartość protocol.http.EmptyPath, a Fault Source ma wartość target, oznacza to, że adres URL serwera backendu ma pustą ś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 zaktualizować adres URL serwera backendu, czyli target.url dynamicznie za pomocą dowolnych zasad (w ramach przepływu proxy/współdzielonego) w przepływie żądania docelowego, tak aby miał pustą ścieżkę.

  4. Sprawdź, czy zmienna przepływu target.url ma pustą ścieżkę i źródło wartości, wykonując jedną z tych czynności:

    Śledzenie

    Korzystanie z narzędzia Śledzenie

    Jeśli udało Ci się zarejestrować ślad tego błędu, wykonaj czynności opisane w artykule Korzystanie z narzędzia do śledzenia :

    1. Sprawdź, czy target.url ma pustą ścieżkę.
    2. Jeśli tak, sprawdź, które zasady zmodyfikowały lub zaktualizowały wartość target.url, tak aby zawierała pustą ścieżkę.

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

    3. W powyższym przykładowym śledzeniu zwróć uwagę, że zasada JavaScript zmodyfikowała lub zaktualizowała wartość target.url, tak aby zawierała pustą ścieżkę.
    4. Pamiętaj, że target.url ma te komponenty:
      • scheme: https://mocktarget.apigee.net
      • path: empty

    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 dzienników.
    2. Jeśli masz logi, przejrzyj je i:
      1. sprawdź, czy target.url ma pustą ścieżkę,
      2. Sprawdź, czy możesz określić, które zasady zmodyfikowały target.url tak, aby zawierały pustą ś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. Sprawdź konkretne zasady (np. AssignMessage lub JavaScript), które modyfikują lub aktualizują zmienną przepływu target.url, i określ przyczynę aktualizacji target.url, która powoduje, że ścieżka jest pusta.

    Oto kilka przykładów zasad, które nieprawidłowo aktualizują zmienną przepływu target.url, tak aby zawierała pustą ścieżkę, co prowadzi do tego błędu.

    Próbka 1

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

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

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

    Pamiętaj, że target.url ma te komponenty:

    • scheme: https://mocktarget.apigee.net
    • path: empty

    Ścieżka jest pusta, więc Apigee Edge zwraca 500 Internal Server Error z kodem błędu protocol.http.EmptyPath.

    Próbka 2

    Przykład 2. Aktualizowanie zmiennej target.url zasad JavaScript

    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 request.header.Path.

    Przykładowa prośba użytkownika:

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

    W tym przykładzie ścieżka nagłówka nie jest wysyłana w ramach żądania. W związku z tym wartość ścieżki zmiennej w zasadach JavaScriptu to null.

    Przykłady:

    • url = https://mocktarget.apigee.net + path
    • url = https://mocktarget.apigee.net + null
    • target.url = https://mocktarget.apigee.netnull

    Pamiętaj, że target.url ma te komponenty:

    • scheme: https://mocktarget.apigee.netnull
    • path: empty

    Próbka 3

    Przykład 3. Aktualizowanie zmiennej target.url w zasadach AssignMessage za pomocą innej zmiennej

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

    Pamiętaj, że target.url ma te komponenty:

    • scheme: https://mocktarget.apigee.net
    • path: empty

    We wszystkich powyższych przykładach ścieżka w adresie URL serwera backendu, czyli target.url, jest pusta, dlatego Apigee Edge zwraca 500 Internal Server Error z kodem błędu protocol.http.EmptyPath.

Rozdzielczość

Zgodnie ze specyfikacją RFC 3986, sekcja 2: Składniki składni komponent path jest wymagany i musi zawsze zawierać ukośnik (/), nawet jeśli nie ma innych znaków w ramach path. Aby rozwiązać ten problem, wykonaj te czynności:

  1. Upewnij się, że adres URL serwera backendu reprezentowany przez zmienną przepływu target.url zawsze ma niepustą ścieżkę.
    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ływutarget.url używasz innych zmiennych, upewnij się, że nie mają one pustej ścieżki.
    3. Jeśli wykonujesz operacje na ciągach znaków, aby określić wartość zmiennej przepływu target.url, upewnij się, że wynik tych operacji nie zawiera pustej ścieżki.
  2. W przykładach omówionych w sekcji Diagnostyka 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, dodaj ukośnik (/) do zmiennej url, jak pokazano poniżej:

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

    Próbka 2

    Przykład 2. Aktualizowanie zmiennej target.url zasad JavaScript

    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 przekazujesz prawidłową ścieżkę, np. /iloveapis w ramach nagłówka żądania Path, jak pokazano poniżej:

    Przykładowe żądanie:

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

    Próbka 3

    Przykład 3. Aktualizowanie zmiennej target.url w zasadzie AssignMessage za pomocą innej zmiennej

    Dodaj prawidłową ścieżkę w elemencie <Value> zasady AssignMessage. Możesz na przykład użyć ścieżki /json w przypadku interfejsu MockTarget API. Oznacza to, że musisz zmodyfikować element <Value> na https://mocktarget.apigee.net/json, 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/json</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>

Specyfikacja

Apigee Edge oczekuje, że adres URL serwera backendu nie będzie miał pustej ścieżki 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 Apigee, zapoznaj się z sekcją Informacje diagnostyczne, które musisz zebrać.

Musisz zebrać 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.EmptyPath
  • 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