Service de récupération d'URL pour les anciens services groupés

Go Java PHP Python

Cette page explique comment envoyer des requêtes HTTP et HTTPS et recevoir des réponses à l'aide du service de récupération d'URL.

Contrairement à l'environnement d'exécution Python 2 dans lequel App Engine utilise le service de récupération d'URL par défaut pour toutes les requêtes sortantes, vous devez explicitement appeler la bibliothèque urlfetch pour utiliser le service de récupération d'URL dans Python 3.

Cette API est compatible avec les environnements d'exécution de première génération et peut être utilisée lors de la mise à niveau vers des environnements d'exécution de deuxième génération correspondants. Si vous effectuez une mise à jour vers l'environnement d'exécution Python d'App Engine, consultez la page Passer à des environnements d'exécution de deuxième génération pour en savoir plus sur les options de migration des anciens services groupés.

Requêtes

Vous pouvez utiliser le service de récupération d'URL ou les bibliothèques idiomatiques pour émettre des requêtes sortantes. Dans Python, vous pouvez utiliser directement la bibliothèque urlfetch ou les bibliothèques urllib.request ou requests pour envoyer des requêtes HTTP.

Protocoles de requête

Une application peut récupérer une URL à l'aide du protocole HTTP ou HTTPS. Le protocole à utiliser est déduit de celui de l'URL cible.

L'URL à récupérer peut utiliser n'importe quel numéro de port compris dans les plages suivantes :

• 80 – 90
• 440 – 450
• 1024 – 65535

Si le port n'est pas mentionné dans l'URL, il est défini de manière implicite par le protocole. Les requêtes HTTP s'exécutent sur le port 80 et les requêtes HTTPS sur le port 443.

Méthodes de requête

Si vous envoyez des requêtes via le service de récupération d'URL, vous pouvez utiliser l'une des méthodes HTTP suivantes :

• GET
• POST
• PUT
• HEAD
• DELETE
• PATCH

Une requête peut inclure des en-têtes HTTP et, pour les requêtes POST, PUT et PATCH, une charge utile.

Transmettre des requêtes par proxy

Notez que le service de récupération d'URL utilise un proxy compatible HTTP/1.1 afin de récupérer le résultat.

Pour empêcher une application de provoquer une imbrication infinie des requêtes, les gestionnaires de requêtes ne sont pas autorisés à récupérer leur propre URL. Toutefois, une imbrication infinie peut encore être déclenchée par d'autres moyens. Soyez donc prudent si votre application est susceptible d'extraire des requêtes pour des URL fournies par l'utilisateur.

En-têtes de requête

Votre application peut définir des en-têtes HTTP pour les requêtes sortantes.

Par exemple, lors de l'envoi d'une requête HTTP POST, si un en-tête Content-Type n'est pas explicitement défini, l'en-tête est défini sur x-www-form-urlencoded. Il s'agit ici du type de contenu utilisé par les formulaires Web.

Pour des raisons de sécurité, les en-têtes suivants ne peuvent pas être modifiés par l'application :

• Content-Length
• Host
• Vary
• Via
• X-Appengine-Inbound-Appid
• X-Forwarded-For
• X-ProxyUser-IP

Ces en-têtes sont définis sur des valeurs précises par App Engine de manière appropriée. Par exemple, App Engine calcule l'en-tête Content-Length à partir des données de requête et l'ajoute à la requête avant de l'envoyer.

Les en-têtes suivants indiquent l'ID de l'application à l'origine de la requête :

• User-Agent. Cet en-tête peut être modifié, mais App Engine ajoute une chaîne d'identifiant pour permettre aux serveurs d'identifier les requêtes App Engine. La chaîne ajoutée se présente au format "AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", où APPID correspond à l'identifiant de votre application.
• X-Appengine-Inbound-Appid. Cet en-tête ne peut pas être modifié et est ajouté automatiquement si la requête est envoyée via le service de récupération d'URLlorsque le paramètre de redirection est défini sur False.

Délais avant expiration des requêtes

Vous pouvez définir la durée maximale, ou délai avant expiration, d'une requête. Par défaut, le délai avant expiration d'une requête est défini sur 10  secondes.

Vous pouvez envoyer des requêtes synchrones et asynchrones. Le comportement suivant s'applique à l'API URL Fetch :

• Requêtes synchrones : l'appel de récupération attend que l'hôte distant affiche un résultat, puis redonne le contrôle à l'application. Si le temps d'attente maximal pour l'appel de récupération est dépassé, l'appel déclenche une exception.
• Requêtes asynchrones : le service de récupération d'URL démarre la requête, puis affiche immédiatement un objet. L'application peut effectuer d'autres tâches pendant la récupération de l'URL. Lorsque l'application a besoin des résultats, elle appelle une méthode sur l'objet, qui attend la fin de la requête si nécessaire, puis affiche le résultat. Si l'une des requêtes de récupération d'URL est en attente lorsque le gestionnaire de requêtes s'arrête, le serveur d'application attend que toutes les requêtes restantes renvoient un résultat ou expirent avant de renvoyer une réponse à l'utilisateur.

Connexions sécurisées et protocole HTTPS

Votre application peut récupérer une URL en toute sécurité en se connectant à des serveurs sécurisés via le protocole HTTPS. Les données de requête et de réponse sont transmises sur le réseau sous forme chiffrée.

Dans l'API Python, le proxy URL Fetch ne valide pas l'hôte contacté par défaut. Vous pouvez ajouter un argument validate_certificate facultatif à la méthode fetch() pour activer la validation des hôtes.

Remarque : Le module urllib.request ne fournit actuellement aucune méthode pour valider les hôtes.

Réponses

Si vous utilisez l'API URL Fetch, notez que le service de récupération d'URL renvoie toutes les données de réponse, y compris la réponse en elle-même, son code, ses en-têtes et son corps.

Par défaut, si le service de récupération d'URL reçoit une réponse contenant un code de redirection, il suit la redirection. Le service suit jusqu'à cinq réponses de redirection, puis renvoie la ressource finale. Vous pouvez indiquer au service de récupération d'URL de ne pas suivre les redirections et, à la place, de renvoyer une réponse de redirection à l'application.

Remarque : L'API URL Fetch impose des limites de taille de réponse. Si la réponse entrante dépasse la taille maximale, le service de récupération d'URL déclenche une exception. Consultez la section Quotas et limites pour en savoir plus. Vous pouvez indiquer à l'API URL Fetch de tronquer la réponse plutôt que de déclencher une exception. Si vous utilisez les bibliothèques urlfetch, urllib.request ou requests pour récupérer des URL, la réponse est toujours tronquée et aucune exception n'est générée.

Utiliser l'API URL Fetch sur le serveur de développement

Lorsque votre application s'exécute sur le serveur de développement App Engine de votre ordinateur, les appels du service de récupération d'URL sont gérés localement. Le serveur de développement récupère les URL en contactant les hôtes distants directement à partir de votre ordinateur. Pour ce faire, il se sert de la configuration réseau que votre ordinateur utilise pour accéder à Internet, quelle qu'elle soit.

Lors du test des fonctionnalités de récupération d'URL de votre application, assurez-vous que votre ordinateur peut accéder aux hôtes distants.

Quotas et limites de l'API URL Fetch

Pour en savoir plus sur les quotas du service de récupération d'URL, consultez la section Quotas. Pour connaître l'utilisation actuelle du quota de votre application, accédez à la page "Détails des quotas" dans la console Google Cloud.

Accéder à la page des détails des quotas

De plus, les limites suivantes s'appliquent à l'utilisation du service de récupération d'URL :

Limit	Amount
Request size	10 megabytes
Request header size	16 KB (Note that this limits the maximum length of the URL that can be specified in the header)
Response size	32 megabytes
Maximum deadline (request handler)	60 seconds
Maximum deadline (Task Queue and cron job handler)	60 seconds