400 Nieprawidłowe żądanie – HeaderHeader

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

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

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 400 Bad Request

Może też pojawić się 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 określony nagłówek HTTP, który nie może mieć duplikatów w Apigee Edge, pojawia się więcej niż raz z tymi samymi lub różnymi wartościami w żądaniu HTTP wysłanym przez klienta do Apigee Edge.

Zgodnie z sekcją 3.2.2 dokumentu RFC 7230: Field Order, nadawca NIE MOŻE generować w wiadomości wielu pól nagłówka o tej samej nazwie, chyba że cała wartość pola nagłówka jest zdefiniowana jako lista rozdzielona przecinkami [tzn. #(values)] lub pole nagłówka jest a dobrze znanym wyjątkiem. Jeśli Apigee Edge znajdzie określony nagłówek, który nie może mieć duplikatów, więcej niż raz w żądaniu HTTP wysłanym przez klienta, odpowie kodem 400 Bad Request i kodem błędu protocol.http.DuplicateHeader.

Oto możliwe przyczyny tego błędu:

Typowe czynności diagnostyczne

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

Przyczyna: zduplikowany nagłówek w żądaniu

Diagnostyka

1. Określ Fault Code (Kod błędu) i Fault Source (Źródło błędu) zaobserwowanego błędu za pomocą monitorowania interfejsów API lub logów dostępu NGINX, jak opisano w sekcji Typowe czynności diagnostyczne.
2. Jeśli Fault Source (Źródło błędu) ma wartość apigee lub MP, oznacza to, że żądanie wysłane przez aplikację kliencką do Apigee zawiera zduplikowane nagłówki.

3. Rzeczywisty nagłówek, który jest wysyłany więcej niż raz w ramach żądania, możesz określić za pomocą jednej 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, to zapoznaj się z elementem faultstring. Element faultstring zawiera nazwę nagłówka, który został wysłany więcej niż raz.

      Przykładowy komunikat o błędzie:

      "faultstring":"Duplicate Header \"Expires\""

   2. W powyższym komunikacie o błędzie widać, że nagłówek Expires został wysłany więcej niż raz, co widać w elemencie faultstring.

   Rzeczywiste żądanie

   Używanie rzeczywistego żą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 zauważysz, że określony nagłówek pojawia się w żądaniu więcej niż raz z tą samą lub różnymi wartościami, jest to przyczyna 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 przykładowym żądaniu nagłówek Expires został wysłany więcej niż raz. Dlatego to żądanie kończy się błędem 400 Bad Request i kodem błędu: protocol.http.DuplicateHeader.

   2. Jeśli masz dostęp do logów klienta, możesz sprawdzić, czy zawierają one informacje o rzeczywistym żądaniu wysłanym do Apigee Edge, i określić nagłówek, który został wysłany więcej niż raz.

Rozdzielczość

HTTPHeader.Expires=allowDuplicates, multiValued

Specyfikacja

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

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, zapoznaj się z sekcją Informacje diagnostyczne, które musisz zebrać.

Informacje diagnostyczne, które musisz zebrać

Zbierz te informacje diagnostyczne, a następnie 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
• Pełne polecenie curl użyte do odtworzenia błędu 400
• Plik śledzenia żądań do interfejsu API

Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:

• Pełny komunikat o błędzie zaobserwowany w przypadku nieudanych żądań
• Nazwa środowiska
• Pakiet proxy interfejsu API
• Pełne 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 rzeczywistymi wartościami.

• Dzienniki systemowe procesora komunikatów /opt/apigee/var/log/edge-message-processor/logs/system.log