500 Errore interno del server - BadPath

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Sintomo

L'applicazione client riceve un codice di stato HTTP 500 Internal Server Error con il codice di errore protocol.http.BadPath come risposta per le chiamate API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 500 Internal Server Error

Inoltre, potresti visualizzare il seguente messaggio di errore:

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

Possibili cause

Questo errore si verifica se l'URL richiesta del server di backend, rappresentato dalla variabile di flusso target.url, contiene un path che inizia con un punto interrogativo (?) anziché una barra (/), che è non valida.

Come da specifiche RFC 3986, sezione 3: Componenti della sintassi e RFC 3986, sezione 3.3: Percorso:

1. La sintassi URI è costituita dai seguenti componenti:

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. Il componente path è obbligatorio e DEVE iniziare con una barra (/).

Pertanto, se l'URL della richiesta del server di backend ha un componente path che inizia con un punto interrogativo (?) anziché una barra (/), Apigee Edge risponde con 500 Internal Server Error e il codice di errore protocol.http.BadPath.

Ad esempio: se target.url ha il valore https://www.mocktarget.apigee.net?json, si verifica questo errore perché path risulta non valido,in quanto inizia con un punto interrogativo (?) anziché con una barra (/).

Passaggi di diagnostica comuni

Utilizza uno dei seguenti strumenti/tecniche per diagnosticare questo errore:

Causa: l'URL del server di backend (target.url) ha un percorso non valido

Diagnosi

1. Determina il codice di errore e l'origine dell'errore per 500 Internal Server Error utilizzando API Monitoring, Trace Tool o i log di accesso NGINX come spiegato in Passaggi comuni per la diagnosi.
2. Se il codice di errore è protocol.http.BadPath e l'origine dell'errore ha il valore target, significa che l'URL del server di backend ha un percorso non valido.

3. L'URL del server di backend è rappresentato dalla variabile di flusso target.url in Apigee Edge. Questo errore si verifica in genere se tenti di aggiornare l'URL del server di backend (target.url) dinamicamente utilizzando uno qualsiasi dei criteri (all'interno del flusso proxy/condiviso) nel flusso della richiesta di destinazione, in modo che abbia un percorso non valido.

4. Determina se la variabile di flusso target.url ha effettivamente un percorso non valido e la sorgente del suo valore utilizzando uno dei seguenti metodi:

   Traccia

   Utilizzo dello strumento Trace

   Se hai acquisito una traccia per questo errore, segui i passaggi descritti in Utilizzo dello strumento Trace e

   1. Verifica se target.url ha un percorso non valido, ovvero se inizia con un punto interrogativo (?) anziché una barra (/).

   2. In caso affermativo, scopri il criterio che ha modificato o aggiornato il valore di target.url in modo che contenga un percorso non valido.

      Esempio di traccia che mostra la variabile di flusso aggiornata dal criterio JavaScript target.url

      
   3. Nella traccia di esempio riportata sopra, nota che la policy JavaScript ha modificato o aggiornato il valore di target.url in modo che contenga un percorso non valido.
   4. Tieni presente che target.url è composto dai seguenti componenti:
      • scheme: https
      • authority: mocktarget.apigee.net
      • path: ?json

      Il percorso inizia con un punto interrogativo (?) anziché una barra (/), pertanto non è valido.

   Log

   Utilizzare i log nel server di log

   1. Se non hai una traccia di questo errore (un problema intermittente), verifica se hai registrato le informazioni sul valore della variabile di flusso target.url utilizzando criteri come MessageLogging o ServiceCallout nel tuo server di log.
   2. Se hai i log, esaminali e
      1. Verifica se target.url ha un percorso non valido e
      2. Verifica se riesci a determinare le informazioni sulla norma modificata target.url in modo che contenga un percorso non valido

   Proxy API

   Esaminare il proxy API non riuscito

   Se non disponi di una traccia o di log per questo errore, esamina il proxy API non riuscito per determinare cosa ha modificato o aggiornato la variabile di flusso target.url in modo che contenga un percorso non valido. Controlla quanto segue:

   • Il criterio all'interno del proxy API
   • Tutti i flussi condivisi richiamati dal proxy

5. Esamina attentamente la policy specifica (ad esempio AssignMessage o JavaScript) che modifica o aggiorna la variabile di flusso target.url e determina la causa dell'aggiornamento di target.url in modo che abbia un percorso non valido.

   Ecco alcuni esempi di criteri che aggiornano la variabile di flusso target.url in modo errato in modo che contenga un percorso non valido che genera questo errore.

   Esempio 1

   Esempio 1: variabile target.url di aggiornamento delle norme JavaScript

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);

   Nell'esempio precedente, nota che la variabile di flusso target.url viene aggiornata con il valore https://mocktarget.apigee.net?json contenuto in un'altra variabile url.

   Tieni presente che il valore di url è composto dai seguenti componenti:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?json

   Il percorso inizia con un punto interrogativo (?) anziché una barra (/), che è non valido. Pertanto, Apigee Edge restituisce 500 Internal Server Error con il codice di errore protocol.http.BadPath.

   Esempio 2

   Esempio n. 2: aggiornamento della variabile target.url della policy JavaScript in base al valore nell'intestazione della richiesta

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Nell'esempio precedente, nota che la variabile di flusso target.url viene aggiornata concatenando il valore https://mocktarget.apigee.net contenuto in una variabile url e il valore di un'altra variabile path, il cui valore viene recuperato da request.header.Path.

   Se hai accesso alla richiesta o alla traccia effettiva, puoi verificare il valore effettivo trasmesso a request.header.Path.

   Richiesta di esempio effettuata dall'utente

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   In questo esempio, il percorso dell'intestazione non viene inviato come parte della richiesta. Pertanto, il valore della variabile path nel criterio JavaScript è null.

   Pertanto:

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   Tieni presente che il valore di target.url è composto dai seguenti componenti:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?user

   Il percorso inizia con un punto interrogativo (?) anziché una barra (/), che è non valido. Pertanto, Apigee Edge restituisce 500 Internal Server Error con il codice di errore protocol.http.BadPath.

   Esempio n. 3

   Esempio 3: aggiornamento della variabile target.url del criterio AssignMessage

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   Tieni presente che il valore di url è composto dai seguenti componenti:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?echo

   Anche in questo esempio, il percorso inizia con un punto interrogativo (?) anziché con una barra (/), che è non valido. Pertanto, Apigee Edge restituisce 500 Internal Server Error con il codice di errore protocol.http.BadPath.

Risoluzione

Come da specifica dell'URL RFC 3986, sezione 3: Componenti della sintassi, il componente path è obbligatorio e DEVE sempre iniziare con "/". Per risolvere il problema, segui i passaggi riportati di seguito:

1. Assicurati che l'URL del server di backend, rappresentato dalla variabile di flusso target.url, abbia sempre un percorso valido e inizi sempre con una barra (/).
   1. In alcuni casi, potresti non avere un nome risorsa nel percorso, quindi assicurati che il percorso contenga almeno una barra (/).
   2. Se utilizzi altre variabili per determinare il valore della variabile di flusso target.url, assicurati che le altre variabili non abbiano un percorso non valido.
   3. Se esegui operazioni sulle stringhe per determinare il valore della variabile di flusso target.url, assicurati che il risultato o l'esito delle operazioni sulle stringhe non abbia un percorso non valido.

2. Negli esempi discussi in precedenza, puoi risolvere il problema come spiegato di seguito:

   Esempio 1

   Esempio 1: variabile target.url di aggiornamento delle norme JavaScript

   Utilizza una barra (/) anziché un punto interrogativo (?) nella variabile url per risolvere il problema, come mostrato di seguito:

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);

   Esempio 2

   Esempio n. 2: aggiornamento della variabile target.url della policy JavaScript in base al valore nell'intestazione della richiesta

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Assicurati di superare un percorso valido, ad esempio /user come parte dell'intestazione della richiesta Path per risolvere il problema come mostrato di seguito:

   Richiesta di esempio:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   Esempio n. 3

   Esempio 3: aggiornamento della variabile target.url della norma AssignMessage

   Aggiungi un percorso valido nell'elemento <Value> del criterio AssignMessage. ovvero sostituisci il punto interrogativo (?) con una barra (/) nell'elemento <Value> e impostalo su https://mocktarget.apigee.net/echo per risolvere il problema, come mostrato di seguito:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   Specifica

   Apigee Edge prevede che il path componente nell'URL del server di backend DEVE sempre iniziare con una barra (/) come da seguenti specifiche:

   Specifica
   RFC 3986, sezione 3: Componenti della sintassi
   RFC 3986, sezione 3.3: Path

   Se hai ancora bisogno di assistenza da parte dell'assistenza Apigee, vai a Informazioni di diagnostica da raccogliere.

   Deve raccogliere informazioni diagnostiche

   Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e poi contatta l'assistenza Apigee Edge:

   Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

   • Nome organizzazione
   • Nome ambiente
   • Nome del proxy API
   • Completa il comando curl utilizzato per riprodurre 500 Internal Server Error con il codice di errore protocol.http.BadPath
   • File di traccia per le richieste API

   Se sei un utente di Private Cloud, fornisci le seguenti informazioni:

   • Messaggio di errore completo osservato per le richieste non riuscite
   • Nome ambiente
   • Bundle proxy API
   • File di traccia per le richieste API

   • Log di accesso NGINX:

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

     Dove: ORG, ENV 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

   Riferimenti

   Variabili di flusso - target