Cette page décrit comment les applications App Engine envoient des requêtes HTTP/HTTPS et reçoivent des réponses. Pour voir des exemples de code montrant comment envoyer des requêtes HTTP et HTTPS à partir de votre application App Engine, consultez la page Envoyer des requêtes HTTP(S).
Requêtes
Dans l'environnement d'exécution Java 8 d'App Engine, vous pouvez utiliser la classe abstraitejava.net.URLConnection
et les classes associées de la bibliothèque standard Java pour établir des connexions HTTP et HTTPS depuis votre application Java.
Vous pouvez également utiliser l'API URL Fetch d'App Engine, qui fournit une mise en œuvre des méthodes définies dans URLConnection
à l'aide de l'API URL Fetch. Pour obtenir plus d'informations sur l'utilisation des classes natives Java par rapport à l'API URL Fetch, consultez la section Avantages de l'utilisation des appels Java standards au lieu de l'API URL Fetch dans Java 8.
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 la classejava.net.URLConnection
Java standard, vous pouvez utiliser n'importe quelle méthode HTTP compatible.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.
Lors de l'envoi d'une requête POST
HTTP, 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é. Il est ajouté automatiquement si la requête est envoyée via le service de récupération d'URL lorsque le paramètre de redirection est défini surFalse
.
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.
La durée maximale est de 60 secondes pour les requêtes HTTP(S) ainsi que pour les requêtes de file d'attente de tâches et de tâches Cron.
Lors de l'utilisation de la classe abstraite URLConnection
avec URL Fetch, le service utilise le délai de la connexion (setConnectTimeout()
) plus le délai de lecture (setReadTimeout()
) comme durée.
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.
Si vous utilisez l'API URL Fetch, notez que le proxy URL Fetch ne valide pas l'hôte contacté. Le serveur proxy ne peut pas détecter les attaques MITM ("man in the middle") entre App Engine et l'hôte distant lorsque le protocole HTTPS est utilisé.
Vous pouvez utiliser la classe FetchOptions
de l'API URLFetchService
afin d'activer la validation d'hôte.
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 URL Fetch de ne pas suivre les redirections et de renvoyer à la place, une réponse de redirection à l'application.
Utiliser le service de récupération d'URL 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 l'environnement d'exécution Java, vous pouvez utiliser l'APIjava.net.URLConnection
Java standard, dans laquelle ces quotas et limites ne s'appliquent pas, au lieu 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 Google Cloud Console.
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 :
Limite | Volume |
---|---|
Taille d'une requête | 10 Mo |
Taille d'un en-tête de requête | 16 Ko (notez que cela limite la longueur maximale de l'URL pouvant être spécifiée dans l'en-tête) |
Taille d'une réponse | 32 Mo |
Délai maximal pour le gestionnaire de requêtes | 60 secondes |
Délai maximal pour la file d'attente de tâches et le gestionnaire de tâches Cron | 60 secondes |
Étape suivante
Exécutez des exemples de code et obtenez des instructions sur la procédure à suivre pour envoyer des requêtes à partir de l'application sur la page Émettre des requêtes HTTP(S).