Résoudre des problèmes concernant les erreurs de réponse

Cette page explique comment résoudre les erreurs que vous recevez en réponse à une requête adressée à votre API.

BAD_GATEWAY

Si vous recevez un code d'erreur 13 avec le message BAD_GATEWAY, cela signifie que le proxy ESP ne peut pas atteindre le backend du service. Vérifiez les éléments suivants :

reset reason: connection failure

Si vous recevez le code HTTP 503 ou le code gRPC 14 et le message upstream connect error or disconnect/reset before headers. reset reason: connection failure, cela signifie qu'ESPv2 ne peut pas atteindre le backend du service.

Pour résoudre le problème, vérifiez les éléments ci-dessous.

Adresse du backend

Vous devez configurer ESPv2 avec l'adresse de backend appropriée. Problèmes courants :

  • Le schéma de l'adresse de backend doit correspondre au type d'application backend. Les backends OpenAPI doivent être http:// et les backends gRPC doivent être grpc://.
  • Pour ESPv2 déployé sur Cloud Run, le schéma de l'adresse de backend doit être https:// ou grpcs://. Le s indique à ESPv2 de configurer TLS avec le backend.

Résolution DNS

Par défaut, ESPv2 tente de résoudre les noms de domaine en adresses IPv6. Si la résolution IPv6 échoue, ESPv2 revient aux adresses IPv4.

Pour certains réseaux, le mécanisme de remplacement peut ne pas fonctionner comme prévu. À la place, vous pouvez forcer ESPv2 à utiliser des adresses IPv4 via l'option --backend_dns_lookup_family.

Cette erreur est courante si vous configurez un connecteur VPC sans serveur pour ESPv2 déployé sur Cloud Run. Les VPC ne sont pas compatibles avec le trafic IPv6.

API is not enabled for the project

Si vous avez envoyé une clé API dans la requête, un message d'erreur de type "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" (l'API my-api.endpoints.example-project-12345.cloud.goog n'est pas activée pour le projet) indique que la clé API a été créée dans un autre projet Google Cloud que celui hébergeant l'API. Pour résoudre ce problème, vous pouvez soit créer la clé API dans le projet Google Cloud auquel l'API est associée, soit activer l'API dans le projet Google Cloud dans lequel la clé API a été créée.

Service control request failed with HTTP response code 403

Si vous recevez le code d'erreur 14 et le message Service control request failed with HTTP response code 403, cela signifie que l'API Service Control (servicecontrol.googleapis.com) n'est pas activée pour le projet.

  1. Consultez la section Vérifier les services requis pour vous assurer que tous les services requis par Cloud Endpoints et ESP sont activés pour le projet.

  2. Consultez la section Vérifier les autorisations requises pour vous assurer que toutes les autorisations requises pour le compte de service associé à l'instance exécutant ESP sont ajoutées.

Method doesn't allow unregistered callers

ESP répond avec l'erreur Method doesn't allow unregistered callers lorsque vous avez spécifié une clé API dans la section security du document OpenAPI, mais que la requête adressée à l'API ne comporte pas de clé API affectée à un paramètre de requête nommé key.

Si vous devez générer une clé API pour effectuer des appels vers l'API, consultez la section Créer une clé API.

Method does not exist

La réponse Method does not exist signifie que la méthode HTTP (GET, POST ou autre) du chemin d'URL spécifié est introuvable. Pour résoudre ce problème, comparez la configuration de service que vous avez déployée pour vous assurer qu'il y a bien correspondance entre le nom de la méthode et le chemin d'URL que vous envoyez dans la requête :

  1. Dans la console Google Cloud, accédez à la page Services Endpoints pour votre projet.

    Accédez à la page Services Endpoints

  2. Si vous avez plusieurs API, sélectionnez celle à laquelle vous avez envoyé la requête.

  3. Cliquez sur l'onglet Historique des déploiements.

  4. Sélectionnez le dernier déploiement pour voir la configuration du service.

Si la méthode que vous appelez n'apparaît pas dans la section paths du document OpenAPI, ajoutez la méthode, ou ajoutez l'option x-google-allow en haut du fichier :

x-google-allow: all

Cette option vous permet d'éviter de répertorier toutes les méthodes compatibles avec le backend dans le document OpenAPI. Avec all, tous les appels, avec ou sans clé API ou authentification des utilisateurs, arrivent à l'API en passant par le proxy ESP. Voir x-google-allow pour en savoir plus.

Erreurs spécifiques à l'environnement flexible App Engine

Cette section décrit les réponses d'erreur des API déployées dans l'environnement flexible App Engine.

Code d'erreur 502 ou 503

App Engine peut prendre quelques minutes pour répondre favorablement aux requêtes. Si vous envoyez une requête et que vous recevez une erreur HTTP HTTP 502, 503 ou une autre erreur de serveur, attendez une minute et envoyez-la de nouveau.

Message d'erreur BAD_GATEWAY

Un code d'erreur 502 contenant BAD_GATEWAY dans le message indique généralement qu'App Engine a arrêté l'application pour cause de mémoire insuffisante. La VM par défaut de l'environnement flexible App Engine ne dispose que de 1 Go de mémoire, avec seulement 600 Mo pour le conteneur d'applications.

Pour résoudre le code d'erreur 502, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Journalisation:

    Accéder à la page "Explorateur de journaux"

  2. Sélectionnez le projet Google Cloud en haut de la page.

  3. Sélectionnez Application Google App Engine et ouvrez le fichier vm.syslog.

  4. Recherchez une entrée de journal semblable à ceci :

    kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

    Si l'entrée Out of memory apparaît dans le journal, procédez comme suit :

    1. Ajoutez les éléments suivants au fichier app.yaml pour augmenter la taille de la VM par défaut :

      resources:
  memory_gb: 4

    2. Redéployez l'API :

      gcloud app deploy

Si l'option rollout_strategy: managed est spécifiée dans la section endpoints_api_service du fichier app.yaml, utilisez la commande suivante pour redéployer l'API :

  gcloud app deploy

Voir Déployer l'API et ESP pour en savoir plus.

Vérifier les journaux Cloud Logging

Pour utiliser les journaux Cloud Logging afin de résoudre les erreurs de réponse, suivez les étapes suivantes :

  1. Dans la console Google Cloud, accédez à la page Logging.

    Accéder à la page "Explorateur de journaux"

  2. En haut de la page, sélectionnez le projet Google Cloud.

  3. À l'aide du menu déroulant situé à gauche, sélectionnez API produite > [NOM_DE_VOTRE_SERVICE].

  4. Ajustez la période jusqu'à voir une ligne indiquant votre erreur de réponse.

  5. Développez la charge utile JSON et recherchez error_cause.

    • Si error_cause est défini sur application, cela indique un problème dans votre code.

    • Si la error cause est d'un autre problème et que vous ne parvenez pas à résoudre le problème, exporter le journal et les inclure dans toutes vos communications avec Google.

Pour en savoir plus, lisez les informations ci-après.

Problèmes avec l'exemple Invoke-WebRequest

Dans certaines versions de Windows PowerShell, l'exemple Invoke-WebRequest dans le tutoriels est défaillant. Nous avons également reçu un rapport indiquant que la réponse contenait une liste d'octets non signés devant être convertis en caractères. Si l'exemple Invoke-WebRequest n'a pas renvoyé le résultat attendu, essayez d'envoyer la requête à l'aide d'une autre application. Voici quelques suggestions :

  • Démarrez Cloud Shell et suivez les instructions Linux du tutoriel que vous avez utilisé pour envoyer la requête.

  • Installez une application tierce telle que l'extension Postman du navigateur Chrome (disponible sur www.getpostman.com). Lors de la création de la requête dans Postman :

    • Sélectionnez POST comme verbe HTTP.
    • Pour l'en-tête, sélectionnez la clé content-type et la valeur application/json.
    • Pour le corps, saisissez : {"message":"hello world"}.

    • Dans l'URL, utilisez la clé API réelle plutôt que la variable d'environnement. Exemple :

      • Dans l'environnement flexible App Engine : https://example-project-12345.appspot.com/echo?key=AIza...
      • Sur d'autres backends : http://192.0.2.0:80/echo?key=AIza...

  • Téléchargez et installez curl, que vous exécutez dans l'invite de commande. Comme Windows ne gère pas les guillemets doubles imbriqués dans les guillemets simples, vous devez modifier l'option --data dans l'exemple, comme suit :

    --data "{\"message\":\"hello world\"}"