502 Bad Gateway – Réponse 405 sans autorisation d'en-tête

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de la surveillance des API:

1. Connectez-vous à l'interface utilisateur Edge en tant qu'utilisateur disposant du rôle approprié.

2. Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.

   
3. Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.

5. Tracez le code d'erreur par rapport à l'heure.

6. Sélectionnez une cellule avec le code d'erreur protocol.http.Response405WithoutAllowHeader, comme indiqué ci-dessous:

   

7. Les informations sur le code d'erreur protocol.http.Response405WithoutAllowHeader sont affichées comme indiqué ci-dessous:

   

8. Cliquez sur Afficher les journaux , puis développez l'une des requêtes ayant échoué pour afficher plus d'informations.

   
9. Dans la fenêtre Journaux, notez les détails suivants :
   • Code d'état:502
   • Source de l'erreur: target
   • Code d'erreur:protocol.http.Response405WithoutAllowHeader.
10. Si la source d'erreur est target et que le code d'erreur est protocol.http.Response405WithoutAllowHeader, cela signifie que le serveur backend a répondu avec le code d'état 405 Method Not Allowed sans l'en-tête Allow.

Outil de traçage

Pour diagnostiquer l'erreur à l'aide de l'outil Trace:

1. Activez la session de trace, puis effectuez l'une des opérations suivantes :
   • Attendez que l'erreur 502 Bad Gateway se produise.
   • Si vous pouvez reproduire le problème, effectuez un appel d'API pour le reproduire (erreur 502 Bad Gateway).

2. Assurez-vous que l'option Show all FlowInfos (Afficher tous les FlowInfos) est activée:

   
3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
4. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.

5. L'erreur apparaît généralement dans un flux après la phase Request sent to target server (Requête envoyée au serveur cible), comme indiqué ci-dessous:

   

6. Notez la valeur de l'erreur dans la trace.

   L'exemple de trace ci-dessus affiche l'erreur sous la forme Received 405 Response without Allow Header. Étant donné que l'erreur est générée par Apigee après l'envoi de la requête au serveur backend, cela indique que celui-ci a envoyé le code d'état de réponse 405 sans l'en-tête Allow.

7. Accédez à la phase AX (Données analytiques enregistrées) dans la trace et cliquez dessus.

8. Faites défiler la page jusqu'à la section Error / Response Headers (En-têtes d'erreur/de réponse) du panneau Phase Details (Détails de la phase), puis déterminez les valeurs de X-Apigee-fault-code et de X-Apigee-fault-source, comme indiqué ci-dessous:

   
9. Les valeurs X-Apigee-fault-code et X-Apigee-fault-source s'afficheront respectivement sous protocol.http.Response405WithoutAllowHeader et target, indiquant que cette erreur est causée par le fait que le backend a envoyé le code d'état de la réponse 405 sans l'en-tête Allow.

   En-têtes de réponse	Valeur
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX, procédez comme suit:

1. Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations essentielles sur les erreurs HTTP 502.

2. Vérifiez les journaux d'accès NGINX:

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

   Où:ORG, ORG et PORT# sont remplacés par des valeurs réelles.

3. Recherchez s'il existe des erreurs 502 avec le code d'erreur protocol.http.Response405WithoutAllowHeader pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours avec 502.

4. Si vous trouvez des erreurs 502 avec le X-Apigee-fault-code correspondant à la valeur de protocol.http.Response405WithoutAllowHeader, déterminez la valeur de la source X-Apigee-fault-code .

   Exemple d'erreur 502 à partir du journal d'accès NGINX:

   

   L'exemple d'entrée ci-dessus du journal d'accès NGINX contient les valeurs suivantes pour X-Apigee- fault-code et X-Apigee-fault-source :

   En-têtes de réponse	Valeur
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

Serveur backend

Option 1 : Corriger le serveur backend pour qu'il envoie un code d'état 405 avec l'en-tête "Allow" (Autoriser)

1. Assurez-vous que le serveur backend respecte toujours la spécification RFC 7231, section 6.5.5: 405 Method Not Allowed et envoie le code d'état 405 en incluant la liste des méthodes autorisées dans un en-tête Allow, comme indiqué ci-dessous:

   Allow: HTTP_METHODS
   

2. Par exemple, si votre serveur backend autorise les méthodes GET, POST et HEAD, vous devez vous assurer que l'en-tête Allow les contient comme suit :

   Allow: GET, POST, HEAD
   

Gestion des erreurs

Option 2: utilisez la gestion des pannes pour envoyer un code d'état 405 avec l'en-tête "Allow" (Autoriser) à partir de votre proxy d'API:

Si le serveur backend renvoie le code d'état 405 sans l'en-tête Allow, vous pouvez utiliser la gestion des pannes pour répondre avec le code d'état 405 et l'en-tête Allow à partir de votre proxy d'API comme suit:

1. Créez une règle telle qu'une règleAssignMessage ou une règle StrikeFault, puis définissez le code d'état sur 405 avec l'en-tête Allow et un message personnalisé.

   Exemple de règle "AssignMessage" pour envoyer une erreur 405 avec l'en-tête "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. Créez un FaultRule dans TargetEndpoint, qui appelle la stratégie lorsque l'erreur 502 est générée avec le code d'erreur protocol.http.Response405WithoutAllowHeader.

   Exemple de configuration TargetEndpoint affichant FaultRule:

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

3. Enregistrez ces modifications dans une nouvelle révision de votre proxy d'API et déployez la révision.
4. Effectuez les appels d'API et vérifiez que vous recevez le code d'état 405 avec l'en-tête Allow.

Configurer la propriété

Option n° 3: configurez la propriété dans le processeur de messages pour empêcher Apigee Edge de renvoyer l'erreur 502

1. Si vous êtes un utilisateur de cloud privé, vous pouvez mettre à jour la propriété HTTP.ignore.allow_header.for.405 sur true pour empêcher Apigee Edge de générer une erreur 502, même si le serveur backend répond par un code d'état 405 sans l'en-tête Allow, à l'aide du guide d'utilisation : Configurer l'en-tête "Ignorer l'autorisation" pour la propriété 405 dans les processeurs de messages.
2. Si vous êtes un utilisateur de cloud public , veuillez contacter l'assistance Apigee Edge.