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:
- Zaloguj się w interfejsie Apigee Edge jako użytkownik o odpowiedniej roli.
Przełącz się na organizację, w której chcesz zbadać problem.
- Otwórz stronę Analiza > Monitorowanie interfejsów API > Zbadaj.
- Wybierz przedział czasu, w którym zaobserwowano błędy.
- Upewnij się, że filtr Serwer proxy jest ustawiony na Wszystkie.
- Porównaj kod błędu z czasem.
Wybierz komórkę z kodem błędu
protocol.http.DuplicateHeader
, jak pokazano poniżej:Informacje o kodzie błędu
protocol.http.DuplicateHeader
są wyświetlane jak poniżej:- Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania.
- W oknie Logi zwróć uwagę na te informacje:
- Kod stanu:
400
- Źródło błędu:
apigee
- Kod błędu:
protocol.http.DuplicateHeader
.
- Kod stanu:
- Jeśli źródło błędu ma wartość
apigee
lubMP
, 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:
- 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
. 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.
- 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 z400
. Jeśli znajdziesz błędy
400
z kodem X-Apigee-fault-code pasującym do wartościprotocol.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
- 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.
- Jeśli źródło błędów ma wartość
apigee
lubMP
, oznacza to, że żądanie wysłane przez aplikację kliencką do Apigee zawiera zduplikowane nagłówki. 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
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\""
- W powyższym komunikacie o błędzie możesz zobaczyć, że nagłówek
Expires
jest wysyłany więcej niż raz, tak jak w interfejsiefaultstring
.
Rzeczywista prośba
Używanie rzeczywistego żądania
Jeśli masz dostęp do rzeczywistego żądania wysłanego przez aplikację kliencką, wykonaj te czynności:
- Sprawdź listę nagłówków przekazanych w żądaniu.
- 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łędem400 Bad Request
i kodem błędu:protocol.http.DuplicateHeader
.- 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
- 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. - 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łówekExpires
tylko raz, jak pokazano poniżej:curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
- 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
- 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. - 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łędu400
- 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łędu400
- 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