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:
- Zaloguj się w interfejsie Apigee Edge jako użytkownik z odpowiedniej roli.
Przełącz się na organizację, w której chcesz zbadać problem.
- Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
- Wybierz okres, w którym zaobserwowano błędy.
- Upewnij się, że filtr serwera proxy jest ustawiony na Wszystkie.
- Porównaj Kod błędu z czasem.
Wybierz komórkę, która ma kod błędu
protocol.http.DuplicateHeader
jak poniżej:Informacje o kodzie błędu
protocol.http.DuplicateHeader
to Jak pokazano 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 –protocol.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:
- 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
. 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.
- 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ę niepowodzeniem400
Jeśli znajdziesz błędy
400
z kodem błędu X-Apigee-fault-code pasujące do wartościprotocol.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
- 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.
- Jeśli Źródło błędu ma wartość
apigee
lubMP
, to wskazuje, że żądanie wysłane przez aplikację kliencką do Apigee zawiera duplikat nagłówki. 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
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\""
- W tym komunikacie o błędzie widać, że nagłówek
Expires
to wysłano więcej niż raz, jak widać wfaultstring
.
Rzeczywiste żądanie
Korzystanie z samego żą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 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łędu400 Bad Request
i kod błędu:protocol.http.DuplicateHeader
.- 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
- 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. - 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 parametrExpires
tylko raz, jak widać poniżej:curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
- 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
- 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. - 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łędu400
- 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łędu400
- 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