Gateway non valido - Risposta 405 senza intestazione Consenti 502

Monitoraggio delle API

Per diagnosticare l'errore utilizzando API Monitoring:

1. Accedi all'UI di Edge come utente con ruolo appropriato.

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

   
3. Vai al menu Analizza > Monitoraggio delle API > Esamina.
4. Seleziona il periodo di tempo specifico in cui hai osservato gli errori.

5. Traccia il codice di errore in base all'ora.

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

   

7. Informazioni sul codice di errore protocol.http.Response405WithoutAllowHeader viene visualizzato 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, tieni presente i seguenti dettagli:
   .
   • Codice di stato: 502
   • Origine errore:target
   • Codice di errore: protocol.http.Response405WithoutAllowHeader.
10. Se Origine di errore è target e Codice di errore è protocol.http.Response405WithoutAllowHeader, questo indica che il backend server ha risposto con il codice di stato 405 Method Not Allowed senza il Allow.

Strumento Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

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

2. Assicurati che l'opzione Mostra tutte le informazioni di Flow sia attivata:

   
3. Seleziona una delle richieste non riuscite ed esamina la traccia.
4. Naviga attraverso le diverse fasi della traccia e individua dove si è verificato l'errore.

5. In genere troverai l'errore in un flusso successivo alla richiesta di richiesta inviata al server di destinazione come illustrato di seguito:

   

6. Prendi nota del valore dell'errore della 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 backend server, 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 registrati di Analytics) della traccia e fai clic su quest'ultima.

8. Scorri verso il basso fino alla sezione Intestazioni errore / risposta dei dettagli della fase. e stabiliamo le 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 targetrispettivamente, che indica che l'errore è causato dall'invio del backend 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 di accesso NGINX:

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

2. Controlla i log di accesso NGINX:

   /opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log

   Dove: ORG, ORG e PORT# vengono sostituiti con valori effettivi.

3. Cerca per vedere se ci sono errori 502 con codice di errore protocol.http.Response405WithoutAllowHeader per un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che non hanno ancora avuto esito positivo 502.

4. Se trovi errori 502 con il X-Apigee-fault-code che corrisponde alla valore di protocol.http.Response405WithoutAllowHeader, quindi determina valore della X-Apigee-fault-source.

   Esempio di errore 502 nel log di accesso NGINX:

   

   La voce di esempio riportata sopra dal log di accesso NGINX ha i seguenti valori per X-Apigee- codice di errore e fonte-fault-X-Apigee:

   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 le specifiche RFC 7231, sezione 6.5.5: 405 Method Not Allowed e invia con lo stato 405 includendo l'elenco dei metodi consentiti in un'intestazione Allow come mostrato di seguito:

   Allow: HTTP_METHODS

2. Ad esempio, se il tuo server di backend consente GET, POST e metodi HEAD, devi assicurarti che l'intestazione Allow 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 dall'API proxy:

Se il server di backend restituisce il codice di stato 405 senza il parametro Allow puoi utilizzare la gestione degli errori per rispondere con il codice di stato 405 e Allow dal proxy API nel seguente modo:

1. Crea un criterio come CriterioAssignMessage o il criterio RaiseFault e imposta il codice di stato su 405 con l'intestazione Allow e una .

   Esempio di criterioAssignMessage per l'invio di un errore 405 con l'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 richiami il criterio quando viene visualizzato l'errore 502 con il codice di errore protocol.http.Response405WithoutAllowHeader.

   Esempio di configurazione dell'endpoint di destinazione 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 Intestazione Allow.

Configura proprietà

Opzione 3: configura la proprietà nel processore di messaggi per impedire ad Apigee Edge la restituzione di un 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 generando un errore 502, anche se il server di backend risponde con 405 senza l'intestazione Allow utilizzando la Guida illustrativa: È in corso la configurazione dell'intestazione Ignora allow per la proprietà 405 nei processori di messaggi.
2. Se sei un utente del cloud pubblico, contatta l'assistenza Apigee Edge