Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Sintomo
L'applicazione client riceve un codice di stato HTTP 502 Bad Gateway
con il codice di errore protocol.http.Response405WithoutAllowHeader
come risposta per le chiamate API.
Messaggio di errore
L'applicazione client riceve il seguente codice di risposta:
HTTP/1.1 502 Bad Gateway
Inoltre, potresti visualizzare il seguente messaggio di errore:
{ "fault":{ "faultstring":"Received 405 Response without Allow Header", "detail":{ "errorcode":"protocol.http.Response405WithoutAllowHeader" } } }
Possibili cause
Questo errore si verifica se il server di backend risponde con il codice di stato 405 Method Not Allowed
senza l'intestazione Allow
.
In base alla specifica
RFC 7231, sezione 6.5.5: 405 Method Not Allowed, si prevede che il server di origine DEVE generare e inviare un campo di intestazione Allow
in una risposta 405
contenente un elenco dei metodi attualmente supportati della risorsa di destinazione. In caso contrario, Apigee risponde con
502 Bad Gateway
e il codice di errore protocol.http.Response405WithoutAllowHeader
.
Causa | Descrizione | Istruzioni per la risoluzione dei problemi applicabili a |
---|---|---|
Risposta 405 senza intestazione Consenti dal server di backend | Il server di backend che elabora la richiesta API risponde con il codice di stato 405 senza intestazione Allow . |
Utenti di cloud pubblico e privato perimetrale |
Passaggi di diagnosi più comuni
Utilizza uno dei seguenti strumenti/tecniche per diagnosticare questo errore:
Monitoraggio delle API
Per diagnosticare l'errore utilizzando il monitoraggio delle API:
- Accedi all'interfaccia utente Edge come utente con un ruolo appropriato.
Passa all'organizzazione in cui vuoi esaminare il problema.
- Vai alla pagina Analizza > Monitoraggio API > Esamina.
- Seleziona il periodo di tempo specifico in cui hai riscontrato gli errori.
Traccia Codice di errore su Ora.
Seleziona una cella con il codice di errore
protocol.http.Response405WithoutAllowHeader
come mostrato di seguito:Le informazioni sul codice di errore
protocol.http.Response405WithoutAllowHeader
vengono visualizzate come mostrato di seguito:Fai clic su Visualizza log ed espandi una delle richieste non riuscite per visualizzare ulteriori informazioni.
- Nella finestra Log, prendi nota dei seguenti dettagli:
- Codice di stato:
502
- Origine errore:
target
- Codice di errore:
protocol.http.Response405WithoutAllowHeader
.
- Codice di stato:
- Se l'origine dell'errore è
target
e il codice di errore èprotocol.http.Response405WithoutAllowHeader
, ciò indica che il server di backend ha risposto con un codice di stato405 Method Not Allowed
senza l'intestazioneAllow
.
Strumento Traccia
Per diagnosticare l'errore utilizzando lo strumento Trace:
- Abilita la
sessione di traccia e
- Attendi che si verifichi l'errore
502 Bad Gateway
oppure - Se riesci a riprodurre il problema, esegui la chiamata API per riprodurlo -
Errore
502 Bad Gateway
- Attendi che si verifichi l'errore
Assicurati che l'opzione Mostra tutte le FlowInfos sia abilitata:
- Seleziona una delle richieste non riuscite ed esamina la traccia.
- Naviga tra le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.
In genere, l'errore si trova in un flusso successivo alla fase Richiesta inviata al server di destinazione, come mostrato di seguito:
Prendi nota del valore dell'errore della traccia.
La traccia di esempio precedente mostra l'errore come
Received 405 Response without Allow Header
. Poiché l'errore viene generato da Apigee dopo l'invio della richiesta al server di backend, indica che il server di backend ha inviato il codice di stato della risposta405
senza l'intestazioneAllow
.- Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic.
Scorri verso il basso fino alla sezione Intestazioni errore / risposta nel riquadro Dettagli fase e determina i valori di X-Apigee-fault-code e X-Apigee-fault-source come mostrato di seguito:
- Vedrai i valori di X-Apigee-fault-code e X-Apigee-fault-source come
protocol.http.Response405WithoutAllowHeader
etarget
, rispettivamente, per indicare che questo errore è causato dal fatto che il backend ha inviato il codice di stato della risposta405
senza l'intestazioneAllow
.Intestazioni della risposta Valore X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
X-Apigee-fault-source target
NGINX
Per diagnosticare l'errore utilizzando i log degli accessi di NGINX:
- Se sei un utente Private Cloud, puoi utilizzare i log degli accessi di NGINX per determinare le informazioni chiave sugli errori HTTP
502
. Controlla i log degli accessi di NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
Dove: ORG, ORG e PORT# vengono sostituiti con i valori effettivi.
- Cerca per vedere se si sono verificati errori
502
con il codice di erroreprotocol.http.Response405WithoutAllowHeader
durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non funzionare con502
. Se riscontri errori
502
con X-Apigee-fault-code corrispondenti al valore diprotocol.http.Response405WithoutAllowHeader
, determina il valore di X-Apigee-fault-source.Esempio di errore 502 dal log degli accessi di NGINX:
La voce di esempio sopra riportata dal log degli accessi di NGINX ha i seguenti valori per X-Apigee- fault-code e X-Apigee-fault-source:
Intestazioni della risposta Valore X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
X-Apigee-fault-source target
Causa: risposta 405 senza intestazione Consenti dal server di backend
Diagnostica
- Determina il codice di errore e l'origine dell'errore per
502 Bad Gateway
utilizzando il monitoraggio delle API, lo strumento Trace o i log degli accessi NGINX come spiegato nella sezione Passaggi comuni della diagnostica. - Se il codice di errore è
protocol.http.Response405WithoutAllowHeader
e l'origine del guasto ha il valoretarget
, significa che il server di backend ha risposto con un codice di stato405
senza l'intestazioneAllow
. Di conseguenza, Apigee risponde con502 Bad Gateway
con il codice di erroreprotocol.http.Response405WithoutAllowHeader
.
Risoluzione
Utilizza uno dei seguenti metodi per risolvere il problema:
Server di backend
Opzione 1: correggi il server di backend per inviare il codice di stato 405 con l'intestazione allow:
Assicurati che il server di backend rispetti sempre la specifica RFC 7231, sezione 6.5.5: 405 Method Not Allowed e invii con il codice di stato
405
includendo l'elenco dei metodi consentiti come parte di un'intestazioneAllow
, come mostrato di seguito:Allow: HTTP_METHODS
- Ad esempio, se il server di backend consente i metodi
GET
,POST
eHEAD
, devi assicurarti che l'intestazioneAllow
li contenga come segue:Allow: GET, POST, HEAD
Gestione dei guasti
Opzione 2: utilizza la gestione dei guasti per inviare il codice di stato 405 con l'intestazione allow dal proxy API:
Se il server di backend restituisce il codice di stato 405
senza l'intestazione Allow
, puoi utilizzare la gestione degli errori per rispondere con il codice di stato 405
e l'intestazione Allow
dal proxy API, nel seguente modo:
Crea un criterio, ad esempio il criterioAssignMessage o il criterio AlzaFault e imposta il codice di stato su
405
con l'intestazioneAllow
e un messaggio personalizzato.Esempio di criterio AssegnaMessage per inviare un errore 405 con intestazione Consenti:
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader"> <DisplayName>AM-405WithAllowHeader</DisplayName> <Set> <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload> <StatusCode>405</StatusCode> <ReasonPhrase>Method Not Allowed</ReasonPhrase> </Set> <Add> <Headers> <Header name="Allow">GET, POST, HEAD</Header> </Headers> </Add> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
Crea un elemento
FaultRule
inTargetEndpoint
, che richiama il criterio dopo aver ricevuto l'errore502
con il codice di erroreprotocol.http.Response405WithoutAllowHeader
.Esempio di configurazione TargetEndpoint che mostra FaultRule:
<TargetEndpoint name="default"> ... <FaultRules> <FaultRule name="405WithoutAllowHeader"> <Step> <Name>AM-405WithAllowHeader</Name> </Step> <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition> </FaultRule> </FaultRules>
- Salva queste modifiche in una nuova revisione del proxy API ed esegui il deployment della revisione.
- Effettua le chiamate API e verifica di ricevere il codice di stato
405
con l'intestazioneAllow
.
Configura proprietà
Opzione 3: configura la proprietà nel processore di messaggi per impedire ad Apigee Edge di restituire l'errore 502
- Se sei un utente del cloud privato, puoi aggiornare la proprietà
HTTP.ignore.allow_header.for.405
atrue
per impedire ad Apigee Edge di generare un errore502
, anche se il server di backend risponde con il codice di stato405
senza l'intestazioneAllow
utilizzando la guida illustrativa: Configurazione dell'intestazione Ignora autorizzazione per la proprietà 405 nei processori di messaggi. - Se sei un utente del cloud pubblico, contatta l'assistenza Apigee Edge
Specifiche
Apigee prevede la risposta 405 Method Not Allowed
dal server di backend insieme all'intestazione Allow
in base alle seguenti specifiche:
Specifiche | |
---|---|
RFC 7231, sezione 6.5.5: 405 Method Not Allowed | |
RFC 7231, sezione 7.4.1: Consenti |
Punti chiave da considerare
La soluzione consigliata consiste nel correggere il server di backend affinché invii il codice di stato 405
con l'intestazione Allow
e rispettare la specifica
RFC 7231, sezione 6.5.5: 405 Method Not Allowed.
Se hai ancora bisogno di aiuto dall'Assistenza Apigee, vai a È necessario raccogliere dati diagnostici.
Devi raccogliere dati diagnostici
Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee Edge.
Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
- Nome dell'organizzazione.
- Nome ambiente
- Nome proxy API
- Comando
curl
completo utilizzato per riprodurre502 Bad Gateway
con il codice di erroreprotocol.http.Response405WithoutAllowHeader
- File di traccia per le richieste API
Se sei un utente Private Cloud, fornisci le seguenti informazioni:
- Messaggio di errore completo osservato per le richieste non riuscite
- Nome ambiente
- Bundle di proxy API
- File di traccia per le richieste API
Log degli accessi NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
Dove: ORG, ORG e PORT# vengono sostituiti con i valori effettivi.
- Log di sistema del processore di messaggi
/opt/apigee/var/log/edge-message-processor/logs/system.log