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 il periodo di tempo specifico in cui hai riscontrato gli errori.

5. Traccia Codice di errore su 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 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 stato 405 Method Not Allowed senza l'intestazione Allow.

Strumento Traccia

Per diagnosticare l'errore utilizzando lo strumento Trace:

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

2. Assicurati che l'opzione Mostra tutte le FlowInfos sia abilitata:

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

5. In genere, l'errore si trova in un flusso successivo alla fase Richiesta inviata al server di destinazione, come mostrato di seguito:

   

6. 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 risposta 405 senza l'intestazione Allow.

7. Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic.

8. 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:

   
9. Vedrai i valori di X-Apigee-fault-code e X-Apigee-fault-source come protocol.http.Response405WithoutAllowHeader e target, rispettivamente, per indicare 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 di NGINX:

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

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

3. Cerca per vedere se si sono verificati 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 ci sono ancora richieste che continuano a non funzionare con 502.

4. Se riscontri errori 502 con X-Apigee-fault-code corrispondenti al valore di protocol.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

Server di backend

Opzione 1: correggi il server di backend per inviare 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 con 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 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:

1. Crea un criterio, ad esempio il criterioAssignMessage o il criterio AlzaFault e imposta il codice di stato su 405 con l'intestazione Allow 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>
   

2. Crea un elemento FaultRule in TargetEndpoint, che richiama il criterio dopo aver ricevuto l'errore 502 con il codice di errore protocol.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>
   

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'intestazione Allow.

Configura 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 del 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: Configurazione dell'intestazione Ignora autorizzazione per la proprietà 405 nei processori di messaggi.
2. Se sei un utente del cloud pubblico, contatta l'assistenza Apigee Edge