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

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:

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

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

   
3. Accédez à Analyser > Surveillance des API > Examiner.
4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.

5. Représentez le code d'erreur par rapport à l'heure.

   <ph type="x-smartling-placeholder">

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

   

7. Informations sur le code d'erreur protocol.http.Response405WithoutAllowHeader s'affiche comme suit:

   

8. Cliquez sur Afficher les journaux et 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: <ph type="x-smartling-placeholder">
   </ph>
   • 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 indique que le backend le serveur a répondu avec le code d'état 405 Method Not Allowed, mais le code Allow.

Outil Trace

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

1. Activez le session trace, et soit <ph type="x-smartling-placeholder">
   </ph>
   • Attendez que l'erreur 502 Bad Gateway se produise.
   • Si vous pouvez reproduire le problème, effectuez l'appel d'API pour le reproduire. 502 Bad Gateway erreur

2. Assurez-vous que l'option Show all FlowInfos (Afficher toutes les infos 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 s'affiche généralement dans un flux après la requête envoyée au serveur cible. comme indiqué ci-dessous:

   

6. Notez la valeur de l'erreur à partir de la trace.

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

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

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

   
9. Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source par protocol.http.Response405WithoutAllowHeader et target, respectivement, indiquant que cette erreur est due au fait que le backend a envoyé 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:

1. Si vous êtes un utilisateur du Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer Informations clés 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. Effectuez une recherche pour voir s'il existe des erreurs 502 avec un code d'erreur protocol.http.Response405WithoutAllowHeader pendant une durée spécifique (si le si le problème s'est produit dans le passé) ou si des requêtes échouent encore 502

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

   Exemple d'erreur 502 dans le 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 n°1: modifiez le serveur backend pour qu'il envoie le code d'état 405 avec l'en-tête "Allow" (Autoriser) :

1. Assurez-vous que le serveur backend respecte toujours la spécification <ph type="x-smartling-placeholder"></ph> RFC 7231, section 6.5.5: 405 Method Not Allowed et envoie avec l'état 405. code 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 GET, POST et HEAD, vous devez vous assurer que l'en-tête Allow contient comme suit:

   Allow: GET, POST, HEAD
   

Gestion des erreurs

Option 2: Utiliser Fault Handling pour envoyer le code d'état 405 avec l'en-tête "Allow" (Autoriser) à partir de votre API proxy:

Si le serveur backend renvoie le code d'état 405 sans Allow vous pouvez utiliser la gestion des pannes pour répondre avec le code d'état 405 et le Allow de votre proxy d'API comme suit:

1. Créez une règle telle que Règle "AssignMessage" ou Règle RaiseFault et définissez le code d'état sur 405 avec l'en-tête Allow et un paramètre .

   Exemple de règle AffectMessage à envoyer 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 règle. lors de l'obtention de l'erreur 502 avec le code d'erreur protocol.http.Response405WithoutAllowHeader

   Exemple de configuration TargetEndpoint montrant 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 obtenez le code d'état 405 avec la Allow.

Configurer la propriété

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

1. Si vous êtes un utilisateur de Private Cloud, vous pouvez mettre à jour la propriété HTTP.ignore.allow_header.for.405 à true pour empêcher Apigee Edge de en générant une erreur 502, même si le serveur backend répond par 405. code d'état sans l'en-tête Allow à l'aide du guide d'utilisation: . Configuration de 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.