Gateway non valido - Risposta 405 senza intestazione Consenti 502

Monitoraggio delle API

Per diagnosticare l'errore utilizzando il monitoraggio delle API:

1. Accedi all'interfaccia utente Edge come utente con un ruolo appropriato.

2. Passa all'organizzazione in cui vuoi esaminare il problema.

   
3. Vai alla pagina Analizza > Monitoraggio API > Esamina.
4. Seleziona l'intervallo di tempo specifico in cui hai osservato gli errori.

5. Traccia Codice di errore rispetto a Ora.

6. Seleziona una cella con il codice di errore protocol.http.Response405WithoutAllowHeader come mostrato di seguito:

   

7. Le informazioni sul codice di errore protocol.http.Response405WithoutAllowHeader vengono visualizzate come mostrato di seguito:

   

8. Fai clic su Visualizza log ed espandi una delle richieste non riuscite per visualizzare ulteriori informazioni.

   
9. Nella finestra Log, prendi nota dei seguenti dettagli:
   • Codice di stato: 502
   • Origine errore: target
   • Codice di errore: protocol.http.Response405WithoutAllowHeader.
10. Se Origine errore è target e Codice di errore è protocol.http.Response405WithoutAllowHeader, significa che il server di backend ha risposto con il codice di stato 405 Method Not Allowed senza l'intestazione Allow.

Strumento Traccia

Per diagnosticare l'errore utilizzando lo strumento Traccia:

1. Attiva la sessione di traccia e
   • Attendi che si verifichi l'errore 502 Bad Gateway oppure
   • Se riesci a riprodurre il problema, effettua la chiamata API per riprodurre l'errore - 502 Bad Gateway

2. Assicurati che l'opzione Mostra tutte le informazioni sul flusso sia attivata:

   
3. Seleziona una delle richieste non riuscite ed esamina la traccia.
4. Esamina le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.

5. In genere, l'errore si verifica in un flusso dopo la fase Richiesta inviata al server di destinazione , come mostrato di seguito:

   

6. Prendi nota del valore dell'errore dalla traccia.

   La traccia di esempio riportata sopra 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 risposta 405 senza l'intestazione Allow.

7. Vai alla fase AX (Dati di analisi registrati) nella traccia e fai clic su di essa.

8. Scorri verso il basso fino alla sezione Intestazioni di errore / risposta nel riquadro Dettagli fase e determina i valori di X-Apigee-fault-code e X-Apigee-fault-source , come mostrato di seguito:

   
9. Vedrai i valori di X-Apigee-fault-code e X-Apigee-fault-source come protocol.http.Response405WithoutAllowHeader e target rispettivamente, il che indica che questo errore è causato dal fatto che il backend ha inviato il codice di stato della risposta 405 senza l'intestazione Allow.

   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 NGINX:

1. Se sei un utente di Private Cloud, puoi utilizzare i log degli accessi NGINX per determinare le informazioni chiave sugli errori HTTP 502.

2. Controlla i 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.

3. Cerca eventuali errori 502 con il codice di errore protocol.http.Response405WithoutAllowHeader durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che non vanno ancora a buon fine con 502.

4. Se trovi errori 502 con X-Apigee-fault-code corrispondente al valore di protocol.http.Response405WithoutAllowHeader, determina il valore di X-Apigee-fault-source.

   Esempio di errore 502 dal log degli accessi NGINX:

   

   La voce di esempio riportata sopra dal log degli accessi 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

Server di backend

Opzione 1: correggi il server di backend in modo che invii il codice di stato 405 con l'intestazione Allow:

1. Assicurati che il server di backend rispetti sempre la specifica RFC 7231, sezione 6.5.5: 405 Method Not Allowed e invii il codice di stato 405 includendo l'elenco dei metodi consentiti come parte di un'intestazione Allow , come mostrato di seguito:

   Allow: HTTP_METHODS

2. Ad esempio, se il server di backend consente i metodi GET, POST e HEAD, devi assicurarti che l'intestazione Allow li contenga come segue:

   Allow: GET, POST, HEAD

Gestione degli errori

Opzione 2: utilizza la gestione degli errori 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 dei guasti per rispondere con il codice di stato 405 e l'intestazione Allow dal proxy API come segue:

1. Crea una policy, ad esempio la policy AssignMessage o RaiseFault e imposta il codice di stato su 405 con l'intestazione Allow e un messaggio personalizzato.

   Esempio di policy AssignMessage per inviare 405 con l'intestazione Allow:

   <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>

2. Crea un FaultRule in TargetEndpoint che richiama la policy quando riceve l'errore 502 con il codice di errore protocol.http.Response405WithoutAllowHeader.

   Esempio di configurazione di TargetEndpoint che mostra FaultRule:

   <TargetEndpoint name="default">
   ...
       <FaultRules>
          <FaultRule name="405WithoutAllowHeader">
               <Step>
                   <Name>AM-405WithAllowHeader</Name>
               </Step>
               <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition>
           </FaultRule>
       </FaultRules>

3. Salva queste modifiche in una nuova revisione del proxy API ed esegui il deployment della revisione.
4. Effettua le chiamate API e verifica di ricevere il codice di stato 405 con l' Allow intestazione.

Configurare la proprietà

Opzione 3: configura la proprietà nel processore di messaggi per impedire ad Apigee Edge di restituire l'errore 502

1. Se sei un utente di cloud privato, puoi aggiornare la proprietà HTTP.ignore.allow_header.for.405 a true per impedire ad Apigee Edge di generare un errore 502, anche se il server di backend risponde con il codice di stato 405 senza l'intestazione Allow utilizzando la guida illustrativa: Configurare la proprietà ignore allow header for 405 nei processori di messaggi.
2. Se sei un utente di Public Cloud, contatta l'assistenza Apigee Edge.