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

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 500 Internal Server Error z kodem błędu protocol.http.EmptyPath.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 500 Internal Server Error

Oprócz tego może pojawić się 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 URL żądania serwera backendu reprezentowany przez zmienną przepływu target.url zawiera pustą ścieżkę.

Zgodnie ze specyfikacją RFC 3986, sekcja 3: Komponenty składni i RFC 3986, sekcja 3.3: Ścieżka:

  1. Składnia identyfikatora URI składa się z tych komponentów:

            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 żadnych innych znaków.

Dlatego jeśli URL żądania serwera backendu w ogóle nie zawiera komponentu path, czyli nie ma nawet ukośnika prawego (/), Apigee Edge w odpowiedzi wysyła 500 Internal Server Error i kod błędu protocol.http.EmptyPath.

Jeśli np. target.url zawiera wartość https://www.mocktarget.apigee.net, ten błąd występuje, gdy 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 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

Procedura 1. Korzystanie z monitorowania interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsu API:

  1. Zaloguj się w interfejsie Apigee Edge jako użytkownik o odpowiedniej roli.
  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. Porównaj kod błędu z czasem.

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

  8. Kliknij Wyświetl logi , aby rozwinąć wiersz z nieudanym żądaniem.

  9. W oknie Logi zwróć uwagę na 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ę.

Trace

Procedura 2. Korzystanie z narzędzia do śledzenia

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

  1. Włącz sesję śledzenia i
    • 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 Show all FlowInfos (Pokaż wszystkie informacje) jest włączona:

  3. Wybierz 1 z nieudanych żądań i sprawdź log czasu.
  4. Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.
  5. Błąd zwykle pojawia się w przepływie po fazie rozpoczęcia docelowego przepływu żądania, jak pokazano poniżej:

  6. Zapisz wartość błędu ze śledzenia.

    błąd: Ścieżka żądania nie może być pusta

    Ponieważ błąd jest zgłaszany przez Apigee Edge po fazie rozpoczęcia docelowego przepływu żądania, wskazuje on, że pole path w adresie URL serwera backendu jest puste. Najczęściej dzieje się tak, jeśli zmienna przepływu target.url (która reprezentuje adres URL serwera backendu) została zaktualizowana o pustą ścieżką w jednej z zasad w przepływie żądania.

  7. Sprawdź sekcję Zmienne odczytane i przypisane w każdym z przepływów wstecz od punktu błędu do fazy rozpoczęcia docelowego przepływu żądania.
  8. Wskaż zasadę, w której aktualizowana jest target.url zmienna przepływu.

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

    W przykładowym logu czasu pokazanym powyżej wartość zmiennej zmiennej przepływu target.url jest aktualizowana w zasadzie JavaScript o nazwie SetTargetURL w następujący sposób:

    target.url : https://mocktarget.apigee.net
    
  9. Pamiętaj, że target.url zawiera te komponenty:
    • schemat: https://mocktarget.apigee.net
    • ścieżka: pusta
  10. Dlatego pojawia się błąd Request path cannot be empty.
  11. Przejdź do fazy AX (rejestrowane dane Analytics) w logu czasu i kliknij ją.
  12. Przewiń w dół do sekcji Szczegóły fazyNagłówki błędów i ustal wartości X-Apigee-fault-code oraz X-Apigee-fault-source, jak pokazano poniżej:

  13. Zobaczysz wartości X-Apigee-fault-code i X-Apigee-fault-source odpowiednio protocol.http.EmptyPath i target , wskazując, ż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. Używanie logów dostępu 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 do określenia kluczowych informacji o HTTP 500 Internal Server Error.
  2. Sprawdź logi dostępu do NGINX:

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

  3. Sprawdź, czy w danym czasie (jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które kończą się niepowodzeniem z 500, sprawdź, czy wystąpiły jakieś błędy 500 z kodem błędu protocol.http.EmptyPath.
  4. Jeśli znajdziesz błędy 500 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 .

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

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

    nagłówków, Wartość
    X-Apigee-fault-code protocol.http.EmptyPath
    X-Apigee-fault-source target

    Zauważ, że wartości X-Apigee-fault-code i X-Apigee-fault-source to protocol.http.EmptyPath oraz 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 urządzenia 500 Internal Server Error za pomocą logów dostępu API Monitoring, narzędzia do śledzenia lub logów dostępu NGINX zgodnie z typowymi czynnościami diagnostycznymi.
  2. Jeśli kod błędu to protocol.http.EmptyPath, a źródło błędu 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 wtedy, gdy próbujesz zaktualizować adres URL serwera backendu, czyli target.url dynamicznie przy użyciu dowolnej zasady (w ramach serwera proxy/przepływu współdzielonego) w docelowym przepływie żądania, tak aby ścieżka miała pustą ścieżkę.

  4. Aby sprawdzić, czy zmienna przepływu target.url rzeczywiście ma pustą ścieżkę, a także źródło jej wartości, wykonaj jedną z tych czynności:

    Trace

    Korzystanie z narzędzia do śledzenia

    Jeśli masz zarejestrowany log czasu związany z tym błędem, wykonaj czynności opisane w sekcji Używanie narzędzia do śledzenia oraz:

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

      Przykładowy ślad pokazujący aktualizację zasady JavaScriptu target.url:

    3. W powyższym przykładowym logu czasu można zauważyć, że zasada JavaScript zmodyfikowała lub zaktualizowała wartość target.url, tak aby zawierała pustą ścieżkę.
    4. Pamiętaj, że target.url zawiera te komponenty:
      • schemat: https://mocktarget.apigee.net
      • ścieżka: pusta

    Logi

    Używanie dzienników na serwerze logów

    1. Jeśli nie masz logu czasu związanego z tym błędem (przejściowym problemem), sprawdź, czy zapisano na serwerze logów informacje o wartości zmiennej przepływu target.url, korzystając z takich zasad jak MessageLogging lub ServiceCallout.
    2. Jeśli masz logi, przejrzyj je i:
      1. Sprawdź, czy pole target.url ma pustą ścieżkę i
      2. Sprawdź, czy możesz ustalić, która zasada zmodyfikowała target.url, tak aby zawierała pustą ścieżkę

    proxy interfejsu API

    Sprawdzanie niedziałającego serwera proxy interfejsu API

    Jeśli nie masz logu czasu ani logów dotyczących tego błędu, sprawdź serwer proxy interfejsu API, który nie działa, aby ustalić, co zmodyfikowało lub zaktualizowało zmienną przepływu target.url, tak aby zawierała nieprawidłową ścieżkę. Wykonaj te czynności:

    • Zasada w ramach serwera proxy interfejsu API
    • Wszystkie udostępnione przepływy wywoływane z serwera proxy
  5. Sprawdź dokładnie konkretną zasadę (np. AssignMessage lub JavaScript), która zmienia lub aktualizuje zmienną przepływu target.url, i określ przyczynę aktualizacji target.url w taki sposób, aby zawierała pustą ścieżkę.

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

    Przykład 1

    Przykład 1. Zasada JavaScript aktualizuje zmienną target.url

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

    W przykładzie powyżej zmienna przepływu target.url jest aktualizowana wartością https://mocktarget.apigee.net znajdującą się w innej zmiennej url.

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

    • schemat: https://mocktarget.apigee.net
    • ścieżka: pusta

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

    Przykład 2

    Przykład 2. Zasady JavaScriptu dotyczące aktualizowania zmiennej target.url

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

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

    Jeśli masz dostęp do rzeczywistego żądania lub logu czasu, możesz zweryfikować rzeczywistą wartość przesłaną do request.header.Path.

    Przykładowe żądanie wysłane przez 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 żądaniu. Dlatego wartość ścieżki zmiennej w zasadzie JavaScriptu wynosi 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 składa się z tych komponentów:

    • schemat: https://mocktarget.apigee.netnull
    • ścieżka: pusta

    Przykład 3

    Przykład 3. Zasady przypisywania wiadomości aktualizujące zmienną target.url 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 składa się z tych komponentów:

    • schemat: https://mocktarget.apigee.net
    • ścieżka: pusta

    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. Komponenty składni, komponent path jest wymagany i MUSI zawsze zawierać ukośnik (/), nawet jeśli path nie zawiera żadnych innych znaków. 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 niepustą ścieżkę.
    1. W niektórych przypadkach nazwa zasobu w ścieżce może nie zawierać nazwy zasobu. Następnie sprawdź, czy ścieżka ma przynajmniej ukośnik (/).
    2. Jeśli używasz innych zmiennych do określania wartości zmiennej przepływu target.url, upewnij się, że pozostałe zmienne nie mają 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 operacji na ciągu znaków nie zawiera pustej ścieżki.
  2. W przykładach omówionych w sekcji Diagnoza możesz rozwiązać ten problem w sposób opisany poniżej:

    Przykład 1

    Przykład 1. Zasady JavaScriptu dotyczące aktualizowania zmiennej target.url

    Aby rozwiązać ten problem, dodaj ukośnik (/) do zmiennej url:

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

    Przykład 2

    Przykład 2. Zasady JavaScriptu dotyczące aktualizowania zmiennej target.url

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

    Aby rozwiązać ten problem, podaj prawidłową ścieżkę, na przykład /iloveapis, w nagłówku żądania Path:

    Przykładowe żądanie:

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

    Przykład 3

    Przykład 3. Zasada AssignMessage aktualizuje zmienną target.url za pomocą innej zmiennej

    Dodaj prawidłową ścieżkę w elemencie <Value> w zasadzie AssignMessage. Możesz na przykład określić /json jako ścieżkę MockTarget API. Zmodyfikuj element <Value> do wartości 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 wymaga, aby adres URL serwera backendu nie ma pustej ścieżki zgodnie z tymi specyfikacjami:

Specyfikacja
RFC 3986, sekcja 3. Komponenty składni
RFC 3986, sekcja 3.3: Ścieżka

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

Konieczne zbieranie informacji diagnostycznych

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe 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 serwera proxy interfejsu API
  • Wykonaj polecenie curl użyte do odtworzenia elementu 500 Internal Server Error z kodem błędu protocol.http.EmptyPath
  • 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 środowiska
  • Pakiet proxy interfejsu API
  • Plik śledzenia żądań 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 wiadomości /opt/apigee/var/log/edge-message- processor/logs/system.log

Odniesienia

Zmienne przepływu – cel