En-têtes de requêtes et réponses

Consultez cette page de référence pour en savoir plus sur les en-têtes HTTP compatibles, ainsi que sur les limites des requêtes et des réponses dans App Engine. Pour comprendre comment App Engine reçoit les requêtes et envoie les réponses, consultez la page Mode de traitement des requêtes.

En-têtes de requête

Une requête HTTP entrante inclut des en-têtes HTTP envoyés par le client. Pour des raisons de sécurité, certains en-têtes sont nettoyés ou modifiés par des serveurs proxy intermédiaires avant d'atteindre l'application.

En-têtes supprimés

Les en-têtes suivants sont supprimés de la requête :

  • Accept-Encoding
  • Connection
  • Keep-Alive
  • Proxy-Authorization
  • TE
  • Trailer
  • Transfer-Encoding

De plus, l'en-tête Strict-Transport-Security est supprimé des requêtes envoyées à des domaines autres que appspot.com ou *.appspot.com.

Ces en-têtes concernent le transfert des données HTTP entre le client et le serveur et sont transparents pour l'application. Par exemple, le serveur peut envoyer automatiquement une réponse compressée avec gzip en fonction de la valeur de l'en-tête de requête Accept- Encoding. L'application elle-même n'a pas besoin de savoir quels encodages de contenu peuvent être acceptés par le client.

Requêtes et WSGI

Le serveur détermine l'objet d'application Python à appeler en comparant l'URL de la requête aux formats d'URL du fichier de configuration de l'application. Il appelle ensuite l'objet d'application à l'aide des arguments définis dans la norme WSGI. L'objet d'application exécute les actions adaptées à la requête, prépare ensuite une réponse et la renvoie sous forme de liste de chaînes.

La plupart des applications utilisent un framework, tel que webapp2, pour gérer les requêtes WSGI. webapp2 est inclus dans l'environnement d'exécution Python 2.7.

Requêtes et CGI

Le serveur détermine le script de gestionnaire Python à exécuter en comparant l'URL de la requête aux formats d'URL du fichier de configuration de l'application. Il exécute ensuite le script dans un environnement contenant les données de la requête. Comme décrit dans la norme CGI, le serveur place les données de la requête dans les variables d'environnement et dans le flux d'entrée standard. Le script exécute les actions adaptées à la requête, puis prépare une réponse et la place dans le flux de sortie standard.

La plupart des applications utilisent une bibliothèque pour analyser les requêtes CGI et renvoyer les réponses CGI, comme le module cgi de la bibliothèque standard Python, ou un framework Web connaissant le protocole CGI (tel que webapp). Pour en savoir plus sur les variables d'environnement et le format des données de flux d'entrée, vous pouvez consulter la documentation de CGI.

En-têtes spécifiques à App Engine

En tant que service pour l'application, App Engine ajoute les en-têtes suivants à toutes les requêtes :

X-AppEngine-Country
Pays à l'origine de la requête, sous forme de code de pays ISO 3166-1 alpha-2. App Engine définit ce code à partir de l'adresse IP du client. Notez que les informations relatives au pays ne sont pas dérivées de la base de données WHOIS. Il est possible qu'une adresse IP pour laquelle des informations relatives à un pays sont présentes dans la base de données WHOIS ne contienne pas ces informations dans l'en-tête X-AppEngine-Country. Votre application devrait gérer le code de pays spécial ZZ (pays inconnu).
X-AppEngine-Region
Nom de la région d'où provient la requête. Cette valeur n'a de sens que dans le contexte du pays dans X -AppEngine-Country. Par exemple, si le pays est "États-Unis" et la région est "ca", "ca" signifie "Californie", et non "Canada". La liste complète des valeurs de région valides se trouve dans la norme ISO-3166-2.
X-AppEngine-City
Nom de la ville d'où provient la requête. Par exemple, la valeur d'en-tête d'une requête provenant de Mountain View serait mountain view. Il n'existe pas de liste canonique de valeurs valides pour cet en-tête.
X-AppEngine-CityLatLong
Latitude et longitude de la ville d'où provient la requête. Cette chaîne peut par exemple prendre la forme "37.386051, -122.083851" pour une requête provenant de Mountain View.
Python accepte le même ensemble d'en-têtes HTTP entrants que ceux énumérés ci-dessus y compris, mais sans s'y limiter, les suivants :

  • X-AppEngine-Https, avec l'exemple d'en-tête : "off"
  • X-AppEngine-User-IP, avec l'exemple d'en-tête : "2602:306:3429:520:501f:4a71:9d2c:be5f"
  • X-Cloud-Trace-Context, avec l'exemple d'en-tête : "18ff88cd7f38ff2bf9b79443..."

Pour les gestionnaires login:admin ou login:required spécifiés dans le fichier app.yaml, App Engine fournit également le jeu d'en-têtes suivant :

  • X-AppEngine-User-Email, avec l'exemple d'en-tête : "ange@example.com"
  • X-AppEngine-Auth-Domain, avec l'exemple d'en-tête : "example.com"
  • X-AppEngine-User-ID, avec l'exemple d'en-tête : "100979712376541954724"
  • X-AppEngine-User-Nickname, avec l'exemple d'en-tête : "ange"
  • X-AppEngine-User-Organization, avec l'exemple d'en-tête : "example.com"
  • X-AppEngine-User-Is-Admin, avec l'exemple d'en-tête : "1"

Les services App Engine peuvent ajouter des en-têtes de requête supplémentaires :

  • Les requêtes du service Cron contiennent également un en-tête HTTP :

    X-AppEngine-Cron: true

    Pour en savoir plus, consultez la page Sécuriser les URL pour Cron.

  • Les requêtes provenant d'autres applications App Engine comportent un en-tête identifiant l'application à l'origine de la requête :

    X-Appengine-Inbound-Appid

    Pour en savoir plus, consultez la documentation sur App Identity.

Réponses aux requêtes

Cette documentation sur les en-têtes HTTP s'applique uniquement aux réponses renvoyées aux requêtes HTTP entrantes. La réponse peut être modifiée avant d'être renvoyée au client. Pour les en-têtes HTTP associés aux requêtes sortantes générées par votre code App Engine, consultez la documentation sur les en-têtes pour URLFetch.

En-têtes supprimés

Les en-têtes suivants sont ignorés et supprimés de la réponse :

  • Connection
  • Content-Encoding*
  • Content-Length
  • Date
  • Keep-Alive
  • Proxy-Authenticate
  • Server
  • Trailer
  • Transfer-Encoding
  • Upgrade

* Peut être de nouveau ajouté si la réponse est compressée par App Engine.

De plus, l'en-tête Strict-Transport-Security est supprimé des réponses envoyées par des domaines autres que *.appspot.com.

Les en-têtes dont le nom ou la valeur comporte des caractères non-ASCII sont également supprimés.

En-têtes ajoutés ou remplacés

Les en-têtes suivants sont ajoutés ou remplacés dans la réponse :

Cache-Control, Expires et Vary

Ces en-têtes spécifient la stratégie de mise en cache pour les serveurs proxy intermédiaires (tels que les fournisseurs de services Internet) et les navigateurs. Si votre script définit ces en-têtes, ils ne seront généralement pas modifiés, sauf si la réponse contient un en-tête Set-Cookie ou est générée pour un utilisateur connecté à l'aide d'un compte administrateur. Les gestionnaires statiques définissent ces en-têtes comme indiqué par le fichier de configuration. Si vous ne spécifiez pas l'en-tête Cache-Control, le serveur peut le définir sur private et ajouter un en-tête Vary: Accept-Encoding.

Si vous avez un en-tête de réponse Set-Cookie, l'en-tête Cache-Control sera défini sur private (s'il n'est pas déjà plus restrictif) et l'en-tête Expires sera défini sur la date actuelle (si ce n'est déjà fait). Généralement, cela permettra aux navigateurs de mettre en cache la réponse, mais pas aux serveurs proxy intermédiaires. Ceci est appliqué pour des raisons de sécurité, car si la réponse était mise en cache publiquement, un autre utilisateur pourrait ultérieurement interroger la même ressource et récupérer le cookie du premier utilisateur.

Content-Encoding

En fonction des en-têtes de requête et du type d'en-tête Content-Type de la réponse, le serveur peut compresser automatiquement le corps de la réponse, comme décrit ci-dessus. Dans ce cas, un en-tête Content-Encoding: gzip est ajouté pour indiquer que le corps est compressé. Pour en savoir plus, consultez la page Compression de la réponse.

Content-Length ou Transfer-Encoding

Le serveur ignore toujours l'en-tête Content-Length renvoyé par l'application. Soit il définit Content-Length sur la longueur du corps (après compression, le cas échéant), soit il supprime Content-Length et utilise l'encodage de transfert en bloc (ajout d'un en-tête Transfer-Encoding: chunked).

Content-Type

Si l'en-tête n'est pas spécifié par l'application, le serveur définit un en-tête Content-Type: text/html par défaut.

Date

Doit être défini sur la date et l'heure actuelles.

Server

Doit être défini sur Google Frontend. Le serveur de développement le définit sur Development/x, x correspondant au numéro de version.

Si vous accédez à des pages dynamiques sur votre site alors que vous êtes connecté à l'aide d'un compte administrateur, App Engine inclut des statistiques par requête dans les en-têtes de réponse, par exemple :

X-AppEngine-Estimated-CPM-US-Dollars
Estimation de ce que 1 000 requêtes semblables à celle-ci coûterait en dollars américains.
X-AppEngine-Resource-Usage
Ressources utilisées par la requête, y compris l'heure côté serveur, exprimée en millisecondes.

Les réponses comportant des statistiques d'utilisation des ressources ne seront pas aptes à la mise en cache.

Si l'en-tête X-AppEngine-BlobKey figure dans la réponse de l'application, il sera utilisé, ainsi que l'en-tête X-AppEngine-BlobRange facultatif, pour remplacer le corps par tout ou une partie du contenu d'un blob de Blobstore. Si Content-Type n'est pas spécifié par l'application, il sera défini sur le type MIME du blob. Si une plage est interrogée, l'état de la réponse sera remplacé par 206 Partial Content et un en-tête Content-Range sera ajouté. Les en-têtes X-AppEngine-BlobKey et X -AppEngine-BlobRange seront supprimés de la réponse. Normalement, vous n'avez pas besoin de définir ces en-têtes vous-même, car la classe blobstore_handlers.BlobstoreDownloadHandler les définit. Pour en savoir plus, consultez la page Diffuser un blob.

En-têtes de réponse définis dans la configuration de l'application

Les en-têtes de réponse HTTP personnalisés peuvent être définis par URL pour les chemins d'accès dynamiques et statiques dans le fichier de configuration de votre application. Pour en savoir plus, consultez les sections http_headers dans la documentation de configuration.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement standard App Engine pour Python 2