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

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.BadFormData 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":"Bad Form Data",
      "detail":{
         "errorcode":"protocol.http.BadFormData"
      }
   }
}

Dane formularzy

Zanim przejdziemy do szczegółów rozwiązywania tego problemu, wyjaśnijmy, czym są dane z formularza.

Dane formularza to informacje podane przez użytkownika, zwykle za pomocą formularza HTML zawierającego elementy takie jak okno do wprowadzania danych, przycisk lub pole wyboru. Dane z formularza są zazwyczaj przesyłane jako seria par klucz-wartość w ramach żądań lub odpowiedzi HTTP.

Przesyłanie danych z formularza

  1. Content-Type: application/x-www-form-urlencoded
    • Jeśli rozmiar danych formularza jest mały, dane są wysyłane jako pary klucz-wartość z tymi elementami:

      Przykładowe żądanie z danymi formularza:

      curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
      
    • Wszystkie znaki inne niż alfanumeryczne w kluczach i wartościach są zakodowane procentowo, tzn. są reprezentowane jako trójka znaków %HH składająca się ze znaku procenta i dwóch cyfr szesnastkowych reprezentujących kod ASCII danego znaku.
    • Dlatego nawet jeśli znak procenta (%) jest dozwolony w danych formularza, jest on interpretowany jako początek specjalnej sekwencji ucieczki. Jeśli więc dane formularza mają zawierać znak procenta (%) w kluczu lub wartości, należy je przesłać jako %25, , co odpowiada kodowi ASCII znaku procenta (%).
  2. Content-Type: multipart/form-data

    Jeśli chcesz przesyłać duże ilości danych binarnych lub tekstu zawierającego znaki inne niż ASCII, możesz wysłać dane za pomocą Content-Type: multipart/form-data, jak opisano w  Formularze – sekcja 17.13.4.2.

Możliwe przyczyny

Ten błąd występuje tylko wtedy, gdy są spełnione wszystkie te warunki:

  1. Żądanie HTTP wysłane przez klienta do Apigee Edge zawiera:
    1. Content-Type: application/x-www-form-urlencoded i
    2. Dane formularza ze znakiem procenta (%) lub znakiem procenta (%) po którym następują nieprawidłowe znaki szesnastkowe, które są niedozwolone zgodnie z  Formularze – sekcja 17.13.4.1.
  2. Serwer proxy interfejsu API w Apigee Edge odczytuje konkretne parametry formularza zawierające znaki, których nie można używać w przepływie żądania, za pomocą zasad ExtractVariables lub AssignMessage.

    Ten błąd występuje na przykład, gdy dane formularza zawierają znak procenta (%) w niezmienionej postaci (bez kodowania) lub znak procenta (%), po którym w kluczu lub wartości występują nieprawidłowe znaki szesnastkowe.

    Oto możliwe przyczyny tego błędu:

    Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
    Parametry formularza w żądaniu zawierają niedozwolone znaki Parametry formularza przekazywane przez klienta w ramach żądania HTTP zawierają znaki, których nie można używać. 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

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.BadFormData, jak pokazano poniżej:

    (wyświetl większy obraz)

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

    (wyświetl większy obraz)

  8. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania.

  9. W oknie Dzienniki zanotuj te informacje:
    • Kod stanu: 500
    • Źródło błędu: proxy
    • Kod błędu: protocol.http.BadFormData
    • Zasady dotyczące błędów: extractvariables/EV-ExtractFormParams
  10. Jeśli Źródło błędu ma wartość proxy, Kod błędu ma wartość protocol.http.BadFormData, a Zasady dotyczące błędu nie są puste, oznacza to, że błąd wystąpił podczas odczytywania lub wyodrębniania danych z formularza (parametrów formularza) przez konkretne zasady wskazane w polu Zasady dotyczące błędu. Dane te zawierają znaki, których nie można używać.
  11. W tym przykładzie wartość X-Apigee-fault-policy to extractvariables/EV- ExtractFormParams, , co oznacza, że zasada ExtractVariables o nazwie EV-ExtractFormParams nie działała prawidłowo podczas odczytywania lub wyodrębniania parametrów formularza.

Narzędzie śledzenia

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 jednych z zasad, jak pokazano poniżej:

    W powyższym przykładowym śledzeniu zwróć uwagę, że błąd wystąpił w zasadach ExtractVariables o nazwie EV-ExtractFormParams.

  6. Otwórz przepływ o nazwie Error po konkretnej zasadzie, która nie została spełniona:

  7. Zapisz te wartości ze śladu:

    błąd: Bad Form Data

    state: PROXY_REQ_FLOW

    error.class: com.apigee.rest.framework.BadRequestException

    • Wartość błędu Bad Form Data wskazuje, że parametry formularza zawierały znaki, których nie można używać.
    • Wartość stanu PROXY_REQ_FLOW, wskazuje, że błąd wystąpił w przepływie żądania serwera proxy interfejsu API.
  8. W śladzie przejdź do fazy AX (Analytics Data Recorded) i kliknij ją.
  9. Przewiń w dół do sekcji Szczegóły fazy – Nagłówki błędów i określ wartości X-Apigee-fault-code, X-Apigee-fault-source i X-Apigee-fault-policy, jak pokazano poniżej:

  10. Pamiętaj, że wartości X-Apigee-fault-code i X-Apigee-fault-source to odpowiednio protocol.http.BadFormData i policy, a X-Apigee-fault-policy nie jest puste. Oznacza to, że błąd wystąpił, gdy zasada wskazana w nagłówku X-Apigee-fault-policy odczytywała lub wyodrębniała dane formularza (parametry formularza), które zawierały znaki niedozwolone do użycia.

    Nagłówki odpowiedzi Wartość
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  11. W tym przykładzie X-Apigee-fault-policy to extractvariables/EV- ExtractFormParams, , co oznacza, że zasada ExtractVariables o nazwie EV-ExtractFormParams nie powiodła się podczas odczytywania lub wyodrębniania parametrów formularza.

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, aby określać kluczowe informacje 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 500błędów z kodem błęduprotocol.http.BadFormData lub czy nadal występują błędy w żądaniach z kodem 500.
  4. Jeśli znajdziesz błędy 500, w których X-Apigee-fault-code ma wartość protocol.http.BadFormData, sprawdź wartości X-Apigee-fault-source i X-Apigee-fault-policy.

    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.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  5. Pamiętaj, że wartości X-Apigee-fault-code i X-Apigee-fault-source to odpowiednio protocol.http.BadFormData i policy , a wartość X-Apigee-fault-policy nie jest pusta. Oznacza to, że błąd wystąpił, gdy zasada wskazana w nagłówku X-Apigee-fault-policy odczytywała lub wyodrębniała dane formularza (parametry formularza), które zawierały znaki niedozwolone.
  6. W tym przykładzie wartość X-Apigee-fault-policy to extractvariables/EV- ExtractFormParams, , co oznacza, że zasada ExtractVariables o nazwie EV-ExtractFormParams nie powiodła się podczas odczytywania parametrów formularza.

Przyczyna: parametry formularza w żądaniu zawierają niedozwolone znaki

Diagnostyka

  1. Określ kod błędu, źródło błędu i zasady dotyczące błędu dla 500 Internal Server Error za pomocą monitorowania interfejsu API, narzędzia do śledzenia lub dzienników dostępu NGINX zgodnie z opisem w typowych krokach diagnostycznych.
  2. Jeśli Fault Code ma wartość protocol.http.BadFormData, Fault Source ma wartość proxy lub policy, a Fault Policy nie jest puste, oznacza to, że zasada określona w Fault Policy nie została spełniona podczas odczytywania lub wyodrębniania danych z formularza (parametrów formularza).
  3. Sprawdź zasady wskazane w sekcji Fault Policy i określ te informacje:
    1. Źródło: określ, czy zasady odczytują lub wyodrębniają dane z żądania czy z odpowiedzi.
    2. Parametry formularza: określ konkretne parametry formularza, które są odczytywane w zasadach.

      Próbka 1

      Przykład 1. Zasada ExtractVariables wyodrębniająca parametry formularza:

            <ExtractVariables name="EV-ExtractFormParms">
               <DisplayName>EV-ExtractFormParams</DisplayName>
               <Source>request</Source>
               <FormParam name="username">
                  <Pattern ignoreCase="false">{username}</Pattern>
               </FormParam>
               <FormParam name="password">
                 <Pattern ignoreCase="false">{password}</Pattern>
               </FormParam>
               <VariablePrefix>forminfo</VariablePrefix>
             <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            </ExtractVariables>
            

      W zasadach ExtractVariables powyżej:

      • Źródło: request

        Wskazuje na to element <Source>.

      • Parametry formularza: username i password

        Wskazuje to element <Pattern> w elemencie <FormParam>.

      Oznacza to, że parametry formularza username lub password przekazane w ramach żądania HTTP przez klienta do Apigee Edge zawierają znaki, których nie można używać.

      Próbka 2

      Przykład 2. Kopiowanie parametrów formularza przez zasadę AssignMessage:

            <AssignMessage continueOnError="false" enabled="true" name="AM-CopyFormParams">
              <Copy source="request">
                <FormParams>
                  <FormParam name="username"/>
                  <FormParam name="password"/>
                </FormParams>
              </Copy>
              <AssignTo createNew="true" transport="http" type="request"/>
            </AssignMessage>
            

      W zasadach ExtractVariables powyżej:

      • Źródło: request

        Wskazuje to atrybut source w elemencie <Copy>.

      • Parametry formularza: username i password

        Wskazuje to atrybut name w elemencie <FormParam>.

      Oznacza to, że parametry formularza username lub password albo oba przekazane w ramach żądania HTTP przez klienta do Apigee Edge zawierają znaki, których nie można używać.

  4. Sprawdź, czy w parametrach formularza zidentyfikowanych w kroku 3 nie ma niedozwolonych znaków, korzystając z jednej z tych metod:

    Narzędzie śledzenia

    Aby przeprowadzić weryfikację za pomocą narzędzia Śledzenie:

    1. Jeśli udało Ci się zarejestrować log czasu nieudanego żądania zgodnie z instrukcjami w sekcji Typowe czynności diagnostyczne, wybierz jedno z nieudanych żądań.
    2. Jeśli okaże się, że parametry formularza zawierające znaki, których nie można używać, są częścią żądania HTTP w kroku 3 powyżej, wykonaj następujące czynności:
      1. Przejdź do etapu Prośba otrzymana od klienta.
      2. Przewiń w dół do sekcji Szczegóły etapu i sprawdź Prośbę o treści.

        ( wyświetl większy obraz)

      3. W powyższym przykładzie zwróć uwagę, że parametr formularza password zawiera znak procenta (%).
      4. Znak procenta (%) jest też używany do kodowania procentowego znaków specjalnych, więc nie można go używać w danych formularza w niezmienionej postaci.
      5. Dlatego Apigee Edge odpowiada kodem stanu 500 Internal Server Error i kodem błędu protocol.http.BadFormData.

    Rzeczywista prośba

    Aby sprawdzić poprawność za pomocą rzeczywistego żądania:

    1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego do serwera docelowego, przejdź do sekcji Rozwiązanie.
    2. Jeśli masz dostęp do rzeczywistego żądania wysłanego do Apigee Edge, wykonaj te czynności:
      1. Sprawdź zawartość danych formularza i zobacz, czy zawiera ona znaki, których nie można używać, np. znak procenta (%) lub znak procenta (%), po którym następują nieprawidłowe znaki szesnastkowe.

        Próbka 1

        Przykładowe żądanie 1. Dane z formularza jako część żądania

        curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%ZY"
        

        W tym przykładzie zwróć uwagę, że element client_secret zawiera znak procenta (%), po którym występują nieprawidłowe znaki szesnastkowe ZY.

        Próbka 2

        Przykładowe żądanie 2. Dane z formularza przekazywane w pliku:

        curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
        

        Zawartość pliku form_data.xml:

        xml=<user><username>abc1234@google.com</username><password>qwerty12345!@#$%</password></user>

        W tym przykładzie zwróć uwagę, że element password zawiera znak procenta (%), który nie powinien być przekazywany w danych formularza w niezmienionej postaci.

    3. W obu powyższych przykładach dane formularza wysyłane w ramach żądania HTTP do Apigee Edge zawierają znaki, których nie można używać.
    4. Dlatego Apigee Edge odpowiada kodem 500 Internal Server Error z kodem błędu protocol.http.BadFormData.

Rozdzielczość

  1. Upewnij się, że wszystkie znaki specjalne w kluczach i wartościach danych formularza lub parametrów wysyłanych w ramach żądania HTTP przez klienta są zawsze kodowane zgodnie z opisem w sekcji Dane formularza – application/x-www-form-urlencoded.
  2. W przypadku omówionych powyżej przykładów możesz rozwiązać problemy w ten sposób:

    Próbka 1

    Przykład 1. Dane z formularza przekazywane w ramach żądania:

    Używaj prawidłowych znaków szesnastkowych, które odpowiadają kodowi ASCII określonego znaku. Jeśli na przykład chcesz wysłać znak dolara ($), użyj %24, jak pokazano poniżej:

    curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%24"
    

    Próbka 2

    Przykładowe żądanie 2. Dane z formularza przekazywane w pliku:

    curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
    

    Zawartość pliku form_data.xml:

    Użyj kodowania procentowego dla znaku procenta (%), czyli zmodyfikuj plik tak, aby zawierał %25 , jak pokazano poniżej:

    xml=<user><username>abc1234@google.com</username><password>qwerty12345!!@#$%25</password></user>

Specyfikacja

Apigee Edge oczekuje, że dane formularza będą przesyłane zgodnie z tymi specyfikacjami:

Specyfikacja
Dane formularza – application/x-www-form-urlencoded

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
  • Użyto polecenia curl, aby odtworzyć 500 Internal Server Error z kodem błędu protocol.http.BadFormData
  • 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