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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X.
informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 500 Internal Server Error z kod 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ć następujący 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 jest 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 zawsze MUSI zawierać ukośnik (/), nawet jeśli ścieżka nie zawiera żadnych innych znaków.

Dlatego, jeśli URL żądania serwera backendu nie zawiera parametru path nie ma nawet ukośnika (/), więc Apigee Edge odpowiada, podając w odpowiedzi kod 500 Internal Server Error i kod błędu protocol.http.EmptyPath

Na przykład: jeśli target.url zawiera wartość https://www.mocktarget.apigee.net, ten błąd występuje, ponieważ path komponent 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 Edge

Typowe kroki diagnostyki

Użyj jednego z tych narzędzi lub metod, aby zdiagnozować ten błąd:

Monitorowanie interfejsów API

Procedura 1. Korzystanie z monitorowania interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsów API:

  1. Zaloguj się w interfejsie Apigee Edge jako użytkownik z odpowiedniej roli.
  2. Przełącz się na organizację, w której chcesz zbadać problem.

  3. Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
  4. Wybierz okres, w którym zaobserwowano błędy.
  5. Porównaj Kod błędu z czasem.

  6. Wybierz komórkę, która ma kod błędu protocol.http.EmptyPath, jak pokazano poniżej:

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

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

  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łęduprotocol.http.EmptyPath, oznacza to, że adres URL serwera backendu zawiera ciąg pustą ścieżkę.

Śledzenie

Procedura 2. Używanie narzędzia śledzenia

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

  1. Włącz sesję śledzenia i wykonaj jedną z tych czynności:
    • Poczekaj, aż wystąpi błąd 500 Internal Server Error lub
    • Jeśli możesz odtworzyć problem, wykonaj wywołanie interfejsu API, aby odtworzyć problem. 500 Internal Server Error
  2. Sprawdź, czy opcja Show all FlowInfos jest włączona:

  3. Wybierz jedno z nieudanych żądań i sprawdź log czasu.
  4. Przejdź przez różne fazy śledzenia i znajdź miejsca, w których wystąpił błąd.
  5. Błąd pojawia się zwykle w ramach procesu po rozpoczęciu docelowego przepływu żądań. faza, jak poniżej:

  6. Zwróć uwagę na wartość błędu z śladu.

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

    Apigee Edge zgłasza błąd po fazie rozpoczęcia docelowego przepływu żądań, Wskazuje on, że pole path w adresie URL serwera backendu jest puste. To spowoduje najczęściej występuje, jeśli zmienna przepływu target.url (która reprezentuje adres URL serwer backendu ) prawdopodobnie został zaktualizowany przez pustą ścieżkę prowadzącą przez jedną z zasad w przepływu żądań.

  7. Sprawdź sekcję Zmienne przeczytane i przypisane w każdym przepływie odwrotnym do na etapie rozpoczęcia docelowego przepływu żądań.
  8. Ustal zasadę, w której zmienna przepływu target.url jest aktualizowana.

    Przykładowy log czasu pokazujący, że zasada JavaScript zaktualizowała zmienną przepływu target.url:

    W przykładowym logu czasu powyżej zwróć uwagę na wartość zmiennej przepływu target.url jest aktualizowany w zasadzie JavaScript o nazwie SetTargetURL jako następujące:

    target.url : https://mocktarget.apigee.net
    
  9. Pamiętaj, że target.url zawiera te komponenty:
    • schemat: https://mocktarget.apigee.net
    • path: pusta ścieżka
  10. W związku z tym pojawia się błąd Request path cannot be empty.
  11. Przejdź do fazy AX (zarejestrowane dane Analytics) i kliknij ją.
  12. Przewiń w dół do sekcji Phase DetailsError Headers (Nagłówki błędów) i określ wartość wartości X-Apigee-fault-code i X-Apigee-fault-source, jak pokazano poniżej:

  13. Zobaczysz wartości X-Apigee-fault-code i X-Apigee-fault-source jako protocol.http.EmptyPath i target , co oznacza, że Ten błąd jest spowodowany pustą ścieżką adresu URL serwera backendu.
    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, aby określić Kluczowe informacje o HTTP 500 Internal Server Error.
  2. Sprawdź logi dostępu NGINX:

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

  3. Wyszukaj błędy (500) z kodem błędu protocol.http.EmptyPath w określonym czasie (jeśli problem wystąpił u w przeszłości) lub jeśli jakieś żądania z 500 nadal kończą się niepowodzeniem.
  4. Jeśli znajdziesz błędy 500 w dopasowaniu X-Apigee-fault-code wartość protocol.http.EmptyPath, a następnie ustal wartość X-Apigee-fault-source.

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

    Powyższy przykładowy wpis logu dostępu NGINX zawiera następujące wartości dla X- Kod błędu Apigee 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 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 przy użyciu monitorowania interfejsów API, narzędzia Trace Tool lub logów dostępu NGINX, jak opisano w sekcji Najczęstsze czynności diagnostyczne.
  2. Jeśli Kod błędu to protocol.http.EmptyPath, a Źródło błędu – wartość target, oznacza to, że adres URL serwera backendu jest pusty .
  3. URL serwera backendu jest w Apigee reprezentowany przez zmienną przepływu target.url Edge. Zwykle ten błąd występuje przy próbie zaktualizowania adresu URL serwera backendu, czyli target.url dynamicznie przy użyciu zasad (w (serwer proxy/współdzielony) w przepływie żądania docelowego tak, by miał pustą ścieżkę.

  4. Sprawdź, czy zmienna przepływu target.url rzeczywiście ma pustą ścieżkę, a parametr źródła jej wartości, wykonując jeden z tych kroków:

    Śledzenie

    Korzystanie z narzędzia Trace

    Jeśli masz zarejestrowany ślad tego błędu, wykonaj czynności opisane w Korzystanie z narzędzia Trace Tool oraz:

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

      Przykładowy log czasu pokazujący, jak zasada JavaScript zaktualizowała zmienną przepływu target.url:

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

    Logi

    Używanie logów na serwerze logów

    1. Jeśli nie ma danych śledzenia tego błędu (problem przejściowy), sprawdź, czy sprawdź, czy masz zapisane informacje o wartości zmiennej Flow target.url przy użyciu zasad takich jak MessageLogging lub . Objaśnienie dotyczące usługi do serwera logów.
    2. Jeśli masz dzienniki, przejrzyj je i:
      1. Sprawdź, czy ścieżka target.url ma pustą ścieżkę.
      2. Sprawdź, czy możesz określić, która zasada zmodyfikowała target.url , aby zawierał pustą ścieżkę

    proxy interfejsu API

    Sprawdzanie uszkodzonego serwera proxy interfejsu API

    Jeśli nie masz logu czasu ani logów dla tego błędu, sprawdź interfejs API, w którym wystąpił błąd serwera proxy, by określić, co zmodyfikowało lub zaktualizowało zmienną przepływu target.url zawiera nieprawidłową ścieżkę. Sprawdź poniższe kwestie:

    • Zasada w obrębie serwera proxy interfejsu API
    • Wszystkie współdzielone przepływy wywoływane z serwera proxy
  5. Sprawdź konkretną zasadę (np. AssignMessage lub JavaScript), która modyfikuje lub dokładnie aktualizuje zmienną przepływu target.url i określa przyczynę aktualizacji target.url ma pustą ścieżkę.

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

    Przykład 1

    Przykład 1. Aktualizacja zmiennej target.url przez zasadę JavaScriptu

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

    W powyższym przykładzie zwróć uwagę, że zmienna przepływu target.url została zaktualizowana z wartością https://mocktarget.apigee.net zawartą w innej zmiennej url

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

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

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

    Przykład 2

    Przykład 2. Aktualizacja zmiennej target.url przez zasadę JavaScriptu

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

    Zwróć uwagę, że w powyższym przykładzie zmienna przepływu target.url jest aktualizowana o łączenie wartości https://mocktarget.apigee.net zawartej w zmiennej url oraz wartość innej zmiennej path, której wartość jest pobierana z zakresu request.header.Path.

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

    Przykładowe żądanie przesł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 ramach żądania. Dlatego też wartość ścieżki zmiennej w zasadzie JavaScript 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 zawiera te komponenty:

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

    Przykład 3

    Przykład 3. Zasada AssignMessage aktualizuje 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 zawiera te komponenty:

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

    We wszystkich powyższych przykładach ścieżka w adresie URL serwera backendu, czyli Pole target.url jest puste, 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 to wymagane i zawsze MUSI mieć ukośnik (/), nawet jeśli nie ma żadnego inne znaki jako część path. Wykonaj te czynności, aby: rozwiąż ten problem:

  1. Sprawdź, czy adres URL serwera backendu reprezentowany przez zmienną przepływu Ścieżka target.url zawsze ma niepustą ścieżkę.
    1. W niektórych przypadkach ścieżka może nie zawierać nazwy zasobu. Upewnij się, że ścieżka zawiera co najmniej ukośnik (/).
    2. Jeśli używasz innych zmiennych do określenia wartości zmiennej przepływu target.url, a potem upewnij się, że inne 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, a następnie sprawdź, czy wynik lub wynik ciągu znaków operacje nie mają pustej ścieżki.
  2. W przykładach omawianych w sekcji Diagnostyka problem ten można rozwiązać w ten sposób: wyjaśniono poniżej:

    Przykład 1

    Przykład 1. Aktualizacja zmiennej target.url przez zasadę JavaScriptu

    Aby to naprawić, dodaj ukośnik (/) do zmiennej url Jak pokazano poniżej:

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

    Przykład 2

    Przykład 2. Aktualizacja zmiennej target.url przez zasadę JavaScriptu

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

    Upewnij się, że przekazujesz prawidłową ścieżkę, np. /iloveapis, jako część parametru nagłówek żądania Path, aby rozwiązać ten problem, jak pokazano poniżej:

    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> zasady AssignMessage. Dla: możesz na przykład użyć ścieżki /json MockTarget API. Oznacza to, że zmień element <Value> na https://mocktarget.apigee.net/json jak 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 ma pustej ścieżki, zgodnie z z następującą specyfikacją:

Specyfikacja
RFC 3986, sekcja 3: komponenty składni
RFC 3986, sekcja 3.3: ścieżka

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, wejdź na Konieczne jest zbieranie informacji diagnostycznych.

Konieczne zbieranie informacji diagnostycznych

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zwróć uwagę na informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge.

Jeśli jesteś użytkownikiem Public Cloud, 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ń do interfejsu API

Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:

  • Pełny komunikat o błędzie zaobserwowany dla nieudanych żądań
  • Nazwa środowiska
  • Pakiet serwerów 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 przez wartości rzeczywiste.

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

Pliki referencyjne

Zmienne przepływu – cel