Anfrageheader und Antworten

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Hier finden Sie weitere Informationen zu Regions-IDs.

OK

Auf dieser Referenzseite finden Sie Details dazu, welche HTTP-Header unterstützt werden, sowie zu den Limits für Anfragen und Antworten in App Engine. Informationen dazu, wie App Engine Anfragen empfängt und Antworten sendet, finden Sie unter Anfrageverarbeitung.

Anfrageheader

Eine eingehende HTTP-Anfrage enthält die HTTP-Header, die vom Client gesendet werden. Einige Header werden aus Sicherheitsgründen von zwischengeschalteten Proxys bereinigt, berichtigt oder entfernt, bevor sie die Anwendung erreichen.

Aus eingehenden Anfragen entfernte Header

Folgende Header werden aus eingehenden Anfragen entfernt, wenn ein Client sie sendet:

• Header mit Namen, die dem Muster X-Google-* entsprechen. Dieses Namensmuster ist für Google reserviert.

• Header mit Namen, die einem App Engine-spezifischen Header entsprechen. Es werden nur exakte Übereinstimmungen entfernt, wobei die Groß- / Kleinschreibung nicht berücksichtigt wird. Beispiel: Header mit dem Namen X-Appengine-Country oder X-AppEngine-Country werden entfernt, X-Appengine-Cntry jedoch nicht.

Die folgenden Header werden aus eingehenden Anfragen entfernt, da sie sich auf die Übertragung der HTTP-Daten zwischen Client und Server beziehen:

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

Beispielsweise kann der Server abhängig vom Wert des Anfrageheaders Accept-Encoding automatisch eine mit gzip komprimierte Antwort senden. Die Anwendung selbst muss nicht wissen, welche Inhaltscodierungen der Client akzeptieren kann.

Hinweis:Entitätsheader (Header, die sich auf den Anfragetext beziehen) werden nicht bereinigt oder überprüft. Anwendungen sollten deshalb nicht von ihnen abhängig sein. Insbesondere wird der Anfrageheader Content- MD5 unverändert an die Anwendung gesendet, sodass er möglicherweise nicht mit dem MD5-Hashwert des Inhalts übereinstimmt. Außerdem wird der Anfrageheader Content-Encoding vom Server nicht überprüft. Wenn der Client also einen mit gzip komprimierten Anfragetext sendet, kommt dieser in komprimierter Form bei der Anwendung an.

Anfragen und WSGI

Durch Vergleich der URL der Anfrage mit den URL-Mustern in der Konfigurationsdatei der Anwendung ermittelt der Server, welches Python-Anwendungsobjekt aufgerufen werden soll. Anschließend wird das Anwendungsobjekt mit den im WSGI-Standard definierten Argumenten aufgerufen. Das Anwendungsobjekt führt je nach Anfrage die entsprechenden Aktionen durch, bereitet dann eine Antwort vor und gibt sie als eine Liste von Strings zurück.

Die meisten Anwendungen verwenden ein Framework wie webapp2 zur Verarbeitung von WSGI-Anfragen. webapp2 ist Bestandteil der Python 2.7-Laufzeit.

Anfragen und CGI

Warnung: CGI ist aufgrund der Abwärtskompatibilität enthalten, sollte aber nicht verwendet werden. Verwenden Sie nach Möglichkeit WSGI.

Durch Vergleich der URL der Anfrage mit den URL-Mustern in der Konfigurationsdatei der Anwendung ermittelt der Server, welches Python-Handler-Skript aufgerufen werden soll. Anschließend wird das Skript in einer Umgebung ausgeführt, die mit den Anfragedaten gefüllt ist. Wie im CGI-Standard beschrieben, fügt der Server die Anfragedaten in Umgebungsvariablen und in den Standardeingabestream ein. Das Skript führt die der Anfrage entsprechenden Aktionen aus und bereitet eine Antwort vor, die in den Standardausgabestream geschrieben wird.

Die meisten Anwendungen verwenden eine Bibliothek zum Parsen von CGI-Anfragen und zum Zurückgeben von CGI-Antworten, z. B. das cgi-Modul aus der Python-Standardbibliothek, oder ein Web-Framework, das das CGI-Protokoll kennt (z. B. webapp). Weitere Informationen zu den Umgebungsvariablen und zum Format der Eingabestreamdaten finden Sie in der CGI-Dokumentation.

App Engine-spezifische Header

App Engine fügt als Dienst für die Anwendung allen Anfragen die folgenden Header hinzu:

X-Appengine-Country

: Das Land, aus dem die Anfrage stammt, als Ländercode gemäß ISO 3166-1 Alpha-2. App Engine ermittelt diesen Code anhand der IP-Adresse des Clients. Beachten Sie, dass die Länderinformationen nicht aus der WHOIS-Datenbank stammen. Es kann sein, dass eine IP-Adresse mit Länderinformationen in der WHOIS-Datenbank keine Länderinformationen im Header X-Appengine-Country enthält. Ihre Anwendung sollte den speziellen Ländercode ZZ (Land unbekannt) verarbeiten können.

X-Appengine-Region

: Der Name der Region, aus der die Anfrage stammt. Die Interpretation dieses Werts hängt von dem unter X -Appengine-Country angegebenen Land ab. Wenn als Land z. B. "US" und als Region "ca" angegeben ist, steht "ca" für "Kalifornien", nicht für Kanada. Die vollständige Liste der gültigen Regionenwerte finden Sie in der Norm ISO 3166-2.

X-Appengine-City

Der Name der Stadt, aus der die Anfrage stammt. So kann z. B. eine Anfrage aus der Stadt Mountain View den Header-Wert mountain view enthalten. Für diesen Header gibt es keine offizielle Liste gültiger Werte.

X-Appengine-CityLatLong

Der Breiten- und Längengrad der Stadt, aus der die Anfrage stammt. Für eine Anfrage aus Mountain View könnte dieser String etwa "37.386051,-122.083851" lauten.

X-Cloud-Trace-Context

Eine eindeutige Kennung für die Anfrage, die für Cloud Trace und Cloud Logging verwendet wird. Es gibt keine Möglichkeit, diesen Header zu deaktivieren oder die Abtastrate für das Tracing auszuwählen, da alle App Engine-Standardumgebungsanwendungen automatisch verfolgt werden.

X-Forwarded-For: [CLIENT_IP(s)], [global forwarding rule IP]

Eine durch Kommas getrennte Liste von IP-Adressen, über die die Clientanfrage weitergeleitet wurde. Die erste IP-Adresse in dieser Liste ist normalerweise die IP-Adresse des Clients, der die Anfrage erstellt hat. Die folgenden IP-Adressen enthalten Informationen über die Proxyserver, die ebenfalls die Anfrage verarbeitet haben, bevor sie den Anwendungsserver erreicht hat. Beispiel:

X-Forwarded-For: clientIp, proxy1Ip, proxy2Ip

X-Forwarded-Proto [http | https]

Zeigt http oder https je nach dem Protokoll, das der Client für die Verbindung mit der Anwendung verwendet hat.

Der Google Cloud Load Balancer beendet alle https-Verbindungen und leitet dann über http den Traffic an App Engine-Instanzen weiter. Beispiel: Wenn ein Nutzer über https://PROJECT_ID.REGION_ID.r.appspot.com Zugriff auf Ihre Website anfordert, ist der Wert des "X-Forwarded-Proto"-Headers https.

Darüber hinaus kann App Engine folgende Header für die interne Verwendung durch App Engine festlegen:

• X-Appengine-Https
• X-Appengine-User-IP
• X-Appengine-Api-Ticket
• X-Appengine-Request-Log-Id
• X-Appengine-Default-Version-Hostname
• X-Appengine-Timeout-Ms

Von App Engine-Diensten werden ggf. zusätzliche Anfrageheader hinzugefügt:

• Für login:admin- oder login:required-Handler, die in app.yaml angegeben sind, fügt App Engine den folgenden Satz Header hinzu:

  • X-Appengine-User-Email, mit Beispielheader: "[e-mail]"
  • X-Appengine-Auth-Domain, mit Beispielheader: "example.com"
  • X-Appengine-User-ID, mit Beispielheader: "100979712376541954724"
  • X-Appengine-User-Nickname, mit Beispielheader: "ange"
  • X-Appengine-User-Organization, mit Beispielheader: "example.com"
  • X-Appengine-User-Is-Admin, mit Beispielheader: "1"

• Der Dienst für Aufgabenwarteschlangen fügt Anfragen zusätzliche Header hinzu, die Details zur Aufgabe in der Anfrage und zur zugehörigen Warteschlange enthalten.

• Anfragen vom Cron-Dienst fügen folgenden Header hinzu:

  X-Appengine-Cron: true

  Weitere Informationen finden Sie unter URLs für Cron sichern.

• Anfragen von anderen App Engine-Anwendungen enthalten einen Header, mit dem die Anwendung identifiziert wird, von der die Anfrage gesendet wird, sofern die anfragende Anwendung den URL-Abrufdienst verwendet:

  X-Appengine-Inbound-Appid

  Weitere Informationen finden Sie in der Dokumentation zu App Identity.

Antworten auf Anfragen

Diese HTTP-Headerdokumentation gilt nur für Antworten auf eingehende HTTP-Anfragen. Die Antwort wird unter Umständen geändert, bevor sie zurück an den Client geht. Informationen zu HTTP-Headern für ausgehende Anfragen, die aus Ihrem App Engine-Code stammen, finden Sie in der Headerdokumentation zu URLFetch.

Entfernte Header

Die folgenden Header werden ignoriert und aus der Antwort entfernt:

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

* Kann neu hinzugefügt werden, wenn die Antwort von App Engine komprimiert wird.

Header mit Nicht-ASCII-Zeichen im Namen oder Wert werden ebenfalls entfernt.

Hinzugefügte oder ersetzte Header

Die folgenden Header werden in der Antwort hinzugefügt oder ersetzt:

Cache-Control, Expires und Vary

Diese Header bestimmen Caching-Richtlinien für zwischengeschaltete Webproxys (wie das Google Front-End und Internet Service Provider) und Browser. Wenn Ihre App diese Antwortheader festlegt, bleiben sie in der Regel unverändert, es sei denn, Ihre App legt auch einen Set-Cookie-Header fest oder die Antwort wird für einen Nutzer generiert, der mit einem Administratorkonto angemeldet ist.

Wenn Ihre Anwendung einen Set-Cookie-Antwortheader festlegt, wird der Header Cache-Control auf private gesetzt (wenn nicht schon eine restriktivere Einstellung ausgewählt ist) und der Header Expires wird auf das aktuelle Datum gesetzt (wenn nicht bereits ein vergangenes Datum angegeben ist). Das sorgt in der Regel dafür, dass die Antwort in Browsern, nicht jedoch in zwischengeschalteten Proxyservern im Cache gespeichert werden kann. Dies geschieht aus Sicherheitsgründen: Bei einer öffentlich im Cache gespeicherten Antwort könnte ein anderer Nutzer dieselbe Ressource noch einmal anfordern und das Cookie des ersten Nutzers abrufen.

Hinweis: Das Caching ist auf dem Entwicklungsserver standardmäßig sowohl für skriptbasierte als auch für statische Inhalte deaktiviert. Wenn Sie keine Caching-Header angeben, enthält der Cache beim Entwickeln Ihrer Anwendung keine Daten.

Wenn Sie ein WebOb-basiertes Framework (wie webapp oder webapp2) verwenden, legt das Framework den Cache-Control-Header standardmäßig auf no-cache fest. Sie müssen ihn daher überschreiben, wenn Sie ein Caching in Ihren Skript-Handlern verwenden.

Legt Ihre Anwendung den Antwortheader Cache-Control nicht fest, kann der Server diesen auf private setzen und einen Vary: Accept-Encoding-Header hinzufügen.

Weitere Informationen zum Caching, einschließlich der Liste von Vary-Werten, die vom Google Front-End unterstützt werden, finden Sie unter Antwort-Caching.

Content-Encoding

Abhängig von den Anfrageheadern und dem Content-Type der Antwort kann der Server den Antworttext wie oben beschrieben automatisch komprimieren. In diesem Fall wird der Header Content-Encoding: gzip hinzugefügt, um zu zeigen, dass der Text komprimiert ist. Weitere Informationen finden Sie im Abschnitt zur Antwortkomprimierung.

Content-Length oder Transfer-Encoding

Der Server ignoriert immer den von der Anwendung zurückgegebenen Header Content-Length. Der Server setzt Content-Length entweder auf die Länge des Texts (ggf. nach der Komprimierung) oder löscht Content-Length und verwendet die aufgeteilte Transfercodierung (durch Hinzufügen des Headers Transfer-Encoding: chunked).

Content-Type

Falls nicht von der Anwendung angegeben, wird vom Server der Standardheader Content-Type: text/html festgelegt.

Hinweis: Wenn Sie ein WebOb-basiertes Framework (wie webapp oder webapp2) verwenden, ist der Content-Type-Header standardmäßig auf text/html; charset=utf-8 gesetzt. Daher gilt dieser Standardwert (ohne ein Charset-Attribut) nicht.

Date

Wird auf das aktuelle Datum und die aktuelle Uhrzeit eingestellt.

Server

Legen Sie Google Frontend fest. Dieser Wert wird durch den Entwicklungsserver auf Development/x gesetzt, wobei x für die Versionsnummer steht.

Wenn Sie auf dynamische Seiten Ihrer Website zugreifen, während Sie mit einem Administratorkonto angemeldet sind, fügt App Engine anfragebezogene Statistiken in die Antwortheader ein:

X-Appengine-Resource-Usage

: Die von der Anfrage genutzten Ressourcen, einschließlich der serverseitigen Zeit in Millisekunden.

Antworten mit Statistiken zur Ressourcennutzung können nicht im Cache gespeichert werden.

Wenn der Header X-Appengine-BlobKey in der Antwort der Anwendung enthalten ist, wird er zusammen mit dem optionalen Header X-Appengine-BlobRange verwendet, um den Text durch den gesamten Inhalt oder einen Teil des Inhalts eines Blobstore-Blobs zu ersetzen. Wenn Content-Type nicht von der Anwendung angegeben ist, gilt der MIME-Typ des Blobs. Wenn ein Bereich angefordert wird, ändert sich der Antwortstatus in 206 Partial Content und ein Header Content-Range wird hinzugefügt. Die Header X-Appengine-BlobKey und X-Appengine-BlobRange werden aus der Antwort entfernt. Normalerweise müssen Sie diese Header nicht selbst festlegen, da sie durch die Klasse blobstore_handlers.BlobstoreDownloadHandler festgelegt werden. Weitere Informationen finden Sie unter Blobs bereitstellen.

In der Anwendungskonfiguration festgelegte Antwortheader

Benutzerdefinierte HTTP-Antwortheader für dynamische und statische Pfade können in der Konfigurationsdatei Ihrer Anwendung pro URL festgelegt werden. Weitere Informationen finden Sie in den Abschnitten http_headers der Dokumentation zur Konfiguration.