400 Nieprawidłowe żądanie – HeaderHeader

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 400 Bad Request z kodem błędu protocol.http.DuplicateHeader .

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:

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

Możliwe przyczyny

Ten błąd występuje, jeśli konkretny nagłówek HTTP, który nie może mieć duplikatów w Apigee Edge, pojawia się więcej niż raz z takimi samymi lub różnymi wartościami w żądaniu HTTP wysłanym przez klienta do Apigee Edge.

Zgodnie z sekcją 3.2.2 specyfikacji pólRFC 7230: nadawca NIE MOŻE generować wielu pól nagłówka z tą samą nazwą pola w wiadomości, chyba że cała wartość danego pola jest zdefiniowana jako lista rozdzielana przecinkami, [np. #(values)] lub pole nagłówka jest 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, wtedy w odpowiedzi wyświetli 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 wysłane z aplikacji klienckiej do Apigee zawiera zduplikowane nagłówki. 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

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

  8. Informacje o kodzie błędu protocol.http.DuplicateHeader są wyświetlane jak 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łędu – wartość protocol.http.DuplicateHeader, oznacza to, że żądanie HTTP z klienta zawierało zduplikowane nagłówki.

Narzędzie do ś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żywać logów dostępu NGINX do określania kluczowych informacji o błędach HTTP 400.
  2. Sprawdź logi dostępu do NGINX:

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

    Gdzie: ORG, ENV i PORT# są zastępowane rzeczywistymi wartościami.

  3. Sprawdź, czy występują jakieś błędy 400 w danym okresie (jeśli problem występował w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 400.
  4. Jeśli znajdziesz błędy 400 z kodem X-Apigee-fault-code pasującym do wartości protocol.http.DuplicateHeader, sprawdź wartość źródła błędów X-Apigee.

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

    Powyższy przykładowy wpis z logu dostępu NGINX ma następujące wartości kodów X-Apigee- fault-code 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. Znajdź kod błędu i źródło błędu dla błędu zaobserwowanego w logach dostępu API Monitoring lub NGINX zgodnie z opisem w częstych krokach diagnostyki.
  2. Jeśli źródło błędów 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 ustalić, korzystając z jednej z tych metod:

    Komunikat o błędzie

    Korzystanie z komunikatu o błędzie

    1. Jeśli masz dostęp do pełnego komunikatu o błędzie otrzymanego z Apigee Edge, zapoznaj się z dokumentem faultstring. faultstring zawiera nazwę nagłówka, która została wysłana więcej niż raz.

      Przykładowy komunikat o błędzie:

      "faultstring":"Duplicate Header \"Expires\""
      
    2. W powyższym komunikacie o błędzie możesz zobaczyć, że nagłówek Expires jest wysyłany więcej niż raz, tak jak w interfejsie faultstring.

    Rzeczywista prośba

    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 dany nagłówek pojawia się w żądaniu więcej niż raz z tą samą lub różnymi wartościami, jest to przyczyną 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 tym przykładowym żądaniu nagłówek Expires jest wysył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 też sprawdzić, czy masz informacje o rzeczywistym żądaniu wysłanym do Apigee Edge, oraz ustalić nagłówek wysyłany więcej niż raz.

Rozdzielczość

Napraw duplikowanie

Opcja nr 1 [zalecana opcja] Popraw aplikację kliencką, aby nie dodawać duplikatów nagłówków

  1. Sprawdź, dlaczego dany klient wysłał zduplikowany nagłówek. W tym przypadku jest to na przykład Expires. Sprawdź, czy serwery proxy interfejsu API mogą akceptować zduplikowany nagłówek. Zwykle nie jest to pożądane zgodnie ze specyfikacją HTTP RFC7230.
  2. Jeśli nie chcesz, zmodyfikuj aplikację kliencką tak, aby nie wysyłała zduplikowanych nagłówków.

    W podanym wyżej przykładzie zauważyliśmy, że nagłówek Expires jest wysyłany dwukrotnie z tą samą wartością, co nie jest pożądane. Aby rozwiązać ten problem, przekaż nagłówek Expires tylko raz, jak pokazano poniżej:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
    
  3. Jeśli chcesz, aby zduplikowane nagłówki zostały zaakceptowane, przejdź do opcji nr 2 korzystania z właściwości CwC.

CwC

Opcja 2. Użycie właściwości „CwC”

Apigee udostępnia właściwość CwC HTTPHeader.<HeaderName> ,która umożliwia aplikacjom klienckim i serwerom docelowym wysyłanie zduplikowanych nagłówków do serwerów proxy interfejsów API w Apigee Edge.

Usługa CwC Wartości
HTTPHeader.<HeaderName> allowDuplicates,multivalued

Na przykład w modułach przetwarzania wiadomości można ustawić tę właściwość, aby zezwolić na duplikaty i wiele wartości nagłówka Expires.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Jeśli jesteś użytkownikiem Private Cloud, możesz skonfigurować właściwość tak, aby uniemożliwić Apigee Edge zgłaszanie błędu 400 Bad Request, nawet jeśli żądanie zawiera zduplikowane nagłówki, zgodnie z instrukcjami konfigurowania procesorów wiadomości do używania zduplikowanych nagłówków.
  2. Jeśli jesteś użytkownikiem chmury publicznej, skontaktuj się z zespołem pomocy Apigee Edge, aby skonfigurować tę właściwość dla swojej organizacji.

Specyfikacja

Apigee wymaga, aby aplikacja kliencka nie wysyłała zduplikowanych nagłówków w ramach żądania zgodnie z tymi specyfikacjami RFC:

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

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

Musisz zebrać informacje diagnostyczne

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

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