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.

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:

• 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

Anfrageantworten

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.

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.

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

Wenn Sie diesen Header nicht explizit festlegen, erkennt die Klasse http.ResponseWriter den Inhaltstyp am Anfang des Antworttexts und legt den Header Content-Type entsprechend fest.

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.

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.