400 Nieprawidłowe żądanie – HeaderHeader

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 400 Bad Request z kodem błędu protocol.http.DuplicateHeader jako odpowiedź na wywołania interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 400 Bad Request

Możesz też zobaczyć komunikat o błędzie podobny do tego poniżej:

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

Możliwe przyczyny

Ten błąd występuje, jeśli konkretny nagłówek HTTP nie może mieć duplikatów w Apigee Edge, występuje więcej niż raz z tymi samymi lub różnymi wartościami w ramach żądania HTTP wysłanego przez do Apigee Edge.

Zgodnie z RFC 7230, sekcja 3.2.2: kolejność pól, nadawca NIE MOŻE generować wielu nagłówków o tej samej nazwie pola w wiadomości, chyba że pole nagłówka jest zdefiniowane jako lista rozdzielana przecinkami [np. #(values)] lub pole nagłówka jest dobrze znany wyjątek. Jeśli Apigee Edge znajdzie określony nagłówek, który nie może mieć więcej niż raz w żądaniu HTTP wysłanym przez klienta, odpowiada, podając 400 Bad Request i kod błędu protocol.http.DuplicateHeader.

Oto możliwe przyczyny tego błędu:

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Zduplikowany nagłówek w żądaniu Żądanie HTTP z aplikacji klienckiej do Apigee zawiera zduplikowane nagłówki. 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

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. Upewnij się, że filtr serwera proxy jest ustawiony na Wszystkie.
  6. Porównaj Kod błędu z czasem.
  7. Wybierz komórkę, która ma kod błędu protocol.http.DuplicateHeader jak poniżej:

  8. Informacje o kodzie błędu protocol.http.DuplicateHeader to Jak pokazano poniżej:

  9. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania.
  10. W oknie Logi zwróć uwagę na te informacje:
    1. Kod stanu: 400
    2. Źródło błędu: apigee
    3. Kod błędu: protocol.http.DuplicateHeader.
  11. Jeśli Źródło błędu ma wartość apigee lub MP , a Kod błęduprotocol.http.DuplicateHeader, oznacza to, że żądanie HTTP z klient zawierał zduplikowane nagłówki.

Narzędzie śledzenia

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 błędach HTTP 400.
  2. Sprawdź 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.

  3. Wyszukaj błędy 400, aby sprawdzić, czy w danym okresie nie wystąpiły jakieś błędy (jeśli w przeszłości) lub jeśli jakieś żądania nadal kończą się niepowodzeniem 400
  4. Jeśli znajdziesz błędy 400 z kodem błędu X-Apigee-fault-code pasujące do wartości protocol.http.DuplicateHeader, a następnie określić wartość źródła X-Apigee-fault-source..

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

    Powyższy przykładowy wpis z logu dostępu NGINX zawiera następujące wartości dla X-Apigee- kod błędu i X-Apigee-fault-source:

    Nagłówki odpowiedzi Wartość
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source MP

Przyczyna: zduplikowany nagłówek w żądaniu

Diagnostyka

  1. Określ kod błędu i źródło błędu dla błędu zaobserwowanego za pomocą interfejsu API. Monitorowanie lub logi dostępu NGINX zgodnie z opisem w typowych krokach diagnostyki.
  2. Jeśli Źródło błędu ma wartość apigee lub MP, to wskazuje, że żądanie wysłane przez aplikację kliencką do Apigee zawiera duplikat nagłówki.
  3. Aby określić rzeczywisty nagłówek, który jest wysyłany więcej niż raz w ramach żądania, możesz użyć funkcji jedną z tych metod:

    Komunikat o błędzie

    Używanie komunikatu o błędzie

    1. Jeśli masz dostęp do pełnego komunikatu o błędzie otrzymanego z Apigee Edge, przeczytaj faultstring. faultstring zawiera który został wysłany więcej niż raz.

      Przykładowy komunikat o błędzie:

      "faultstring":"Duplicate Header \"Expires\""
      
    2. W tym komunikacie o błędzie widać, że nagłówek Expires to wysłano więcej niż raz, jak widać w faultstring.

    Rzeczywiste żądanie

    Korzystanie z samego żądania

    1. Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację kliencką, wykonaj te czynności:

      1. Sprawdź listę nagłówków przekazanych w żądaniu.
      2. Jeśli dany nagłówek występuje więcej niż raz w sekcji żądania z tą samą wartością lub różnymi wartościami , to właśnie jest przyczyną dla tego błędu.

      Przykładowe żądanie:

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
      

      W powyższym żądaniu nagłówek Expires został wysłany częściej niż raz. W związku z tym żądanie kończy się niepowodzeniem z powodu błędu 400 Bad Request i kod błędu: protocol.http.DuplicateHeader.

    2. Jeśli masz dostęp do dzienników klienta, możesz też sprawdzić, informacje o rzeczywistym żądaniu wysłanym do Apigee Edge oraz określenie nagłówka, który została wysłana więcej niż raz.

Rozdzielczość

Napraw duplikowanie

Opcja 1. [Zalecana opcja] Napraw aplikację kliencką, aby nie zawierała zduplikowanych nagłówków

  1. Przeanalizuj przyczynę, dla której dany klient wysłał zduplikowany nagłówek. Przykład: Expires. Sprawdź, czy serwery proxy interfejsu API mogą akceptować powielony nagłówek. Zwykle nie jest to pożądane ze względu na specyfikację HTTP RFC7230.
  2. Jeśli nie jest to pożądane, zmodyfikuj aplikację kliencką tak, aby nie wysyłała zduplikowanych nagłówków.

    W przykładzie omówionym powyżej można zauważyć, że wysłano nagłówek Expires dwukrotnie z tą samą wartością, co nie jest pożądane. Możesz rozwiązać ten problem, przekazując parametr Expires tylko raz, jak widać poniżej:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
    
  3. Jeśli to możliwe i chcesz zezwolić na zduplikowane nagłówki, otwórz Opcja 2. Korzystanie z usługi CCW.

CwC

Opcja 2. Korzystanie z usługi CCW

Apigee zapewnia Właściwość CwC HTTPHeader.<HeaderName> ,która umożliwia klientowi wysyłanie powielonych nagłówków do serwerów proxy API w Apigee Edge przez aplikacje i serwery docelowe.

Usługa konwersji w aplikacji Wartości
HTTPHeader.<HeaderName> allowDuplicates,multivalued

Na przykład poniższą właściwość można ustawić w procesorach wiadomości, aby umożliwić dostęp do duplikatów i wiele wartości dla nagłówka Expires.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Jeśli jesteś użytkownikiem Private Cloud, możesz skonfigurować usługę tak, aby Apigee Edge powoduje zgłaszanie błędu 400 Bad Request, nawet jeśli żądanie zawiera zduplikowane nagłówki za pomocą operatora Przewodnik po konfigurowaniu procesorów wiadomości pod kątem używania zduplikowanych nagłówków.
  2. Jeśli jesteś użytkownikiem Public Cloud Cloud, skontaktuj się z zespołem pomocy Apigee Edge, aby skonfigurować tę właściwość Twojej organizacji.

Specyfikacja

Apigee oczekuje, że aplikacja kliencka nie będzie wysyłać zduplikowanych nagłówków w ramach żądania zgodnie z następującą specyfikacją RFC:

Specyfikacja
RFC 7230, sekcja 3.2.2: Field Order
RFC 7230, sekcja 3.2 Pola nagłówka

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

Musi zbierać informacje diagnostyczne

Zbierz poniższe 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 błędu 400
  • 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
  • Wykonaj polecenie curl użyte do odtworzenia błędu 400
  • 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.

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