Anfrageverarbeitung

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.

In diesem Dokument wird beschrieben, wie Ihre App Engine-Anwendung Anfragen empfängt und Antworten sendet.

Weitere Informationen finden Sie in der Referenz zu Anfrageheadern und Antworten.

Wenn Ihre Anwendung Dienste verwendet, können Sie Anfragen an einen bestimmten Dienst oder eine bestimmte Version dieses Dienstes richten. Weitere Informationen zur Adressierbarkeit von Diensten finden Sie unter Anfragenrouting.

Verarbeitung von Anfragen

Ihre Anwendung ist für den Start eines Webservers und die Verarbeitung von Anfragen zuständig. Sie können jedes Web-Framework verwenden, das für Ihre Programmiersprache verfügbar ist.

App Engine führt mehrere Instanzen Ihrer Anwendung aus. Jede Instanz hat ihren eigenen Webserver zur Verarbeitung von Anfragen. Jede Anfrage kann an jede Instanz weitergeleitet werden. Daher werden aufeinanderfolgende Anfragen von einem Nutzer nicht zwangsläufig an dieselbe Instanz gesendet. Eine Instanz kann mehrere Anfragen gleichzeitig verarbeiten. Die Anzahl der Instanzen wird automatisch angepasst, wenn sich der Traffic ändert. Sie können auch die Anzahl der gleichzeitigen Anfragen ändern, die eine Instanz verarbeiten kann. Dazu legen Sie in der Datei app.yaml das Element max_concurrent_requests fest.

Wenn App Engine eine Webanfrage für Ihre Anwendung empfängt, wird gemäß Beschreibung in der Konfigurationsdatei app.yaml der Anwendung das Handler-Skript aufgerufen, das der URL entspricht. Die Python 2.7-Laufzeit unterstützt den WSGI-Standard und den CGI-Standard, um eine Abwärtskompatibilität zu erreichen. WSGI wird bevorzugt und ist für einige Funktionen von Python 2.7 Voraussetzung. Die Konfiguration der Skript-Handler Ihrer Anwendung bestimmt, ob eine Anfrage mit WSGI oder CGI verarbeitet wird.

Das folgende Python-Skript antwortet auf eine Anfrage mit einem HTTP-Header und der Hello, World!-Nachricht.

import webapp2


class MainPage(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        self.response.write("Hello, World!")


app = webapp2.WSGIApplication(
    [
        ("/", MainPage),
    ],
    debug=True,
)

Wenn Sie parallel mehrere Anfragen an jeden Webserver senden möchten, markieren Sie die Anwendung als threadsicher. Dazu fügen Sie der app.yaml-Datei das Element threadsafe: true hinzu. Gleichzeitige Anfragen sind nicht verfügbar, wenn von einem der Skript-Handler CGI verwendet wird.

Kontingente und Limits

App Engine weist Ihrer Anwendung automatisch Ressourcen zu, wenn der Traffic zunimmt. Dies ist jedoch an folgende Einschränkungen gebunden:

  • App Engine reserviert Kapazitäten für die automatische Skalierung von Anwendungen mit niedriger Latenz, die Anfragen in weniger als einer Sekunde beantworten.

  • Bei stark an CPUs gebundenen Anwendungen kann die Latenz auch geringfügig höher sein, um Ressourcen gemeinsam mit anderen Anwendungen effizient auf denselben Servern zu nutzen. Anfragen nach statischen Dateien sind von diesen Latenzbeschränkungen ausgenommen.

Alle eingehenden Anfragen an die Anwendung werden auf das Limit für Anfragen angerechnet. Die als Antwort auf eine Anfrage gesendeten Daten werden auf das Limit Ausgehende Bandbreite (kostenpflichtig) angerechnet.

Sowohl HTTP- als auch (sichere) HTTPS-Requests werden auf die Limits Requests, Eingehende Bandbreite (kostenpflichtig) und Ausgehende Bandbreite (kostenpflichtig) angerechnet. In der Google Cloud Console werden außerdem zu Informationszwecken auf der Seite „Kontingentdetails“ als separate Werte Sichere Requests, Sichere eingehende Bandbreite und Sichere ausgehende Bandbreite angezeigt. In diese Werte fließen nur HTTPS-Anfragen ein. Weitere Informationen finden Sie auf der Seite Kontingente.

Die folgenden Limits gelten speziell für die Verwendung von Anfrage-Handlern:

Limit Menge
Größe der Anfrage 32 MB
Größe der Antwort 32 MB
Zeitüberschreitung bei Anfrage Hängt von der Art der Skalierung ab, die Ihre Anwendung verwendet
Maximale Gesamtzahl von Dateien (Anwendungsdateien und statische Dateien) 10.000 insgesamt
1.000 pro Verzeichnis
Maximale Größe einer Anwendungsdatei 32 MB
Maximale Größe einer statischen Datei 32 MB
Maximale Gesamtgröße aller Anwendungsdateien und statischen Dateien Das erste 1 GB ist kostenlos
0,026 $ pro GB pro Monat nach dem ersten GB
Zeitüberschreitung bei ausstehender Anfrage 10 Sekunden
Maximale Größe eines einzelnen Anfrageheaderfelds 8 Kilobyte für Laufzeiten der zweiten Generation in der Standardumgebung. Anfragen an diese Laufzeiten mit Header-Feldern, die 8 Kilobyte überschreiten, geben HTTP 400-Fehler zurück.

Anfragelimits

Alle HTTP/2-Anfragen werden bei der Weiterleitung an den Anwendungsserver in HTTP/1.1-Anfragen umgewandelt.

Antwortlimits

  • Dynamische Antworten sind auf eine Größe von 32 MB beschränkt. Wenn ein Skript-Handler eine Antwort generiert, die diesen Grenzwert überschreitet, sendet der Server eine leere Antwort mit dem Statuscode 500 („Interner Serverfehler“) zurück. Diese Beschränkung gilt nicht für Antworten, die Daten aus dem Legacy-Blobstore oder aus Cloud Storage bereitstellen.

  • Der Antwortheader beträgt bei Laufzeiten der zweiten Generation 8 KB. Antwortheader, die dieses Limit überschreiten, geben HTTP 502-Fehler zurück, wobei Logs upstream sent too big header while reading response header from upstream enthalten.

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 oder berichtigt, bevor sie die Anwendung erreichen.

Weitere Informationen finden Sie in der Referenz zu Anfrageheadern.

Umgang mit Zeitlimits für Anfragen

App Engine ist für Anwendungen mit kurzlebigen Anfragen optimiert, die in der Regel wenige Hundert Millisekunden in Anspruch nehmen. Effiziente Anwendungen antworten schnell auf die meisten Anfragen. Bei Anwendungen, die nicht schnell antworten, ist es unwahrscheinlich, dass sie mit der Infrastruktur von App Engine optimal skalieren. Um dieses Leistungsniveau beizubehalten, gibt es ein vom System festgelegtes maximales Zeitlimit für Anfragen, bis zu dem jede Anwendung antworten muss.

Wenn Ihre Anwendung diese Frist überschreitet, unterbricht App Engine den Anfrage-Handler. Die Python-Laufzeitumgebung erreicht dies, indem sie eine DeadlineExceededError-Ausnahme von google.appengine.runtime auslöst. Falls der Anfrage-Handler diese Ausnahme nicht abfängt, gibt die Laufzeitumgebung, wie es bei allen nicht abgefangenen Ausnahmen der Fall ist, den HTTP-Serverfehler 500 an den Client zurück.

Der Anfrage-Handler kann diesen Fehler abfangen, um die Antwort anzupassen. Die Laufzeitumgebung stellt dem Anfrage-Handler noch einen kurzen Zeitraum (unter einer Sekunde) zur Verfügung, nachdem die Ausnahme ausgelöst wurde, in dem eine angepasste Antwort vorbereitet werden kann.

class TimerHandler(webapp2.RequestHandler):
    def get(self):
        from google.appengine.runtime import DeadlineExceededError

        try:
            time.sleep(70)
            self.response.write("Completed.")
        except DeadlineExceededError:
            self.response.clear()
            self.response.set_status(500)
            self.response.out.write("The request did not complete in time.")

Falls der Handler innerhalb der zweiten Frist keine Antwort zurückgibt oder keine Ausnahme auslöst, wird er beendet und es wird eine Standardfehlerantwort zurückgegeben.

Antworten

In App Engine wird das Handler-Skript mit Requestaufgerufen und auf dessen Antwort gewartet. Alle Daten, die in den Standardausgabestream geschrieben werden, werden als HTTP-Antwort gesendet.

Für die von Ihnen generierte Antwort gelten Größenbeschränkungen und die Antwort kann geändert werden, bevor sie an den Client zurückgegeben wird.

Weitere Informationen finden Sie in der Referenz zu Antworten auf Anfragen.

Streamingantworten

App Engine unterstützt keine Streamingantworten, bei denen Daten in inkrementellen Blöcken an den Client gesendet werden, während eine Anfrage verarbeitet wird. Alle Daten aus Ihrem Code werden wie oben beschrieben erfasst und in einer einzigen HTTP-Antwort gesendet.

Antwortkomprimierung

App Engine versucht, komprimierte (gzip-)Inhalte für Clients bereitzustellen, die diese unterstützen. Um festzustellen, ob Inhalte komprimiert werden sollten, geht App Engine beim Empfang einer Anfrage so vor:

  1. Durch Aufrufen der Header Accept-Encoding und User-Agent in der Anfrage wird geprüft, ob der Client komprimierte Antworten zuverlässig empfangen kann. Durch diese Methode werden einige bekannte Fehler vermieden, die in gängigen Browsern mit gzip-Inhalten auftreten können.

  2. Durch Aufrufen des Headers Content-Type, den Sie für den Antwort-Handler konfiguriert haben, wird geprüft, ob die Komprimierung als Methode geeignet ist. Im Allgemeinen eignet sich eine Komprimierung für textbasierte Inhaltstypen und nicht für binäre Inhaltstypen.

Wichtige Hinweise:

  • Ein Client kann erzwingen, dass textbasierte Inhaltstypen komprimiert werden. Dazu muss für die Anfrageheader Accept-Encoding und User-Agent der Wert gzip festgelegt werden.

  • Wenn gzip nicht im Header der Anfrage Accept-Encoding enthalten ist, komprimiert App Engine die Antwortdaten nicht.

  • Das Google Front-End speichert Antworten von statischen App Engine-Datei- und Verzeichnis-Handlern im Cache. Abhängig von verschiedenen Faktoren, z. B. welche Art von Antwortdaten zuerst im Cache gespeichert wird, welche Vary-Header Sie in der Antwort angegeben haben und welche Header in der Anfrage enthalten sind, kann ein Client möglicherweise eine Anfrage für komprimierte Daten stellen, aber unkomprimierte Daten empfangen und umgekehrt. Weitere Informationen finden Sie unter Antwort-Caching.

Antwort-Caching

Das Google Front-End und möglicherweise der Browser des Nutzers sowie andere zwischengeschaltete Proxyserver für das Caching speichern die Antworten Ihrer Anwendung gemäß den Standard-Caching-Headern, die Sie in der Antwort angeben. Sie können diese Antwortheader entweder über Ihr Framework, direkt in Ihrem Code oder über statische Datei- und Verzeichnis-Handler von App Engine festlegen.

Im Google Front-End ist der Cache-Schlüssel die vollständige URL der Anfrage.

Statische Inhalte im Cache speichern

Damit Clients immer aktualisierte statische Inhalte empfangen, sobald sie veröffentlicht werden, empfehlen wir, statische Inhalte aus versionierten Verzeichnissen wie css/v1/styles.css bereitzustellen. Das Google Front-End führt die Validierung des Caches (seine Prüfung auf aktualisierte Inhalte) erst aus, wenn der Cache abläuft. Auch nach Ablauf des Cache wird der Cache erst aktualisiert, wenn sich der Inhalt der Anfrage-URL ändert.

Die folgenden Antwortheader, die Sie in app.yaml festlegen können, haben Einfluss darauf, wie und wann das Front-End von Google Inhalte im Cache speichert:

  • Cache-Control sollte auf public gesetzt sein, damit das Google Front-End Inhalte im Cache speichern kann. Sie können auch vom Google Front-End im Cache gespeichert werden, sofern Sie nicht die Anweisung Cache-Control private oder no-store angeben. Wenn Sie diesen Header nicht in app.yaml festlegen, fügt App Engine ihn automatisch allen Antworten hinzu, die von einem statischen Datei- oder Verzeichnis-Handler verarbeitet werden. Weitere Informationen finden Sie unter Hinzugefügte oder ersetzte Header.

  • Vary: Damit der Cache basierend auf Headern, die in der Anfrage gesendet werden, unterschiedliche Antworten für eine URL zurückgeben kann, legen Sie im Vary-Anfrageheader einen oder mehrere der folgenden Werte fest: Accept, Accept-Encoding, Origin oder X-Origin

    Aufgrund einer potenziell hohen Kardinalität werden Daten für andere Vary-Werte nicht im Cache gespeichert.

    Beispiel:

    1. Sie geben den folgenden Antwortheader an:

      Vary: Accept-Encoding

    2. Ihre Anwendung erhält eine Anfrage mit dem Header Accept-Encoding: gzip. App Engine gibt eine komprimierte Antwort zurück und das Google Front-End speichert die mit gzip komprimierte Version der Antwortdaten im Cache. Alle nachfolgenden Anfragen für diese URL, die den Header Accept-Encoding: gzip enthalten, empfangen die mit gzip komprimierten Daten aus dem Cache, bis der Cache ungültig wird (weil sich der Inhalt nach Ablauf des Caches ändert).

    3. Ihre Anwendung erhält eine Anfrage ohne den Header Accept-Encoding. App Engine gibt eine unkomprimierte Antwort zurück und das Google Front-End speichert die unkomprimierte Version der Antwortdaten im Cache. Alle nachfolgenden Anfragen für diese URL, die den Header Accept-Encoding nicht enthalten, empfangen die komprimierten Daten aus dem Cache, bis der Cache ungültig wird.

    Wenn Sie keinen Vary-Antwortheader festlegen, erstellt das Google Front-End einen einzelnen Cache-Eintrag für die URL und verwendet ihn für alle Anfragen, unabhängig von den Headern in der Anfrage. Beispiel:

    1. Sie geben den Antwortheader Vary: Accept-Encoding nicht an.
    2. Eine Anfrage enthält den Header Accept-Encoding: gzip und die mit gzip komprimierte Version der Antwortdaten wird im Cache gespeichert.
    3. Eine zweite Anfrage enthält den Header Accept-Encoding: gzip nicht. Da der Cache jedoch eine mit gzip komprimierte Version der Antwortdaten enthält, wird die Antwort auch dann mit gzip komprimiert, wenn der Client nicht komprimierte Daten angefordert hat.

Die Header in der Anfrage haben auch Auswirkungen auf das Caching:

  • Wenn die Anfrage einen Authorization-Header enthält, werden die Inhalte vom Google Front-End nicht im Cache gespeichert.

Cache-Ablauf

Die Caching-Header, die den Antworten durch statische Datei- und Verzeichnis-Handler von App Engine hinzugefügt werden, weisen Clients und Webproxys wie das Google Front-End standardmäßig an, den Cache nach 10 Minuten ablaufen zu lassen.

Nachdem eine Datei mit einer bestimmten Ablaufzeit gesendet wurde, ist es im Allgemeinen nicht möglich, sie aus Webproxy-Caches zu löschen, auch wenn der Nutzer seinen eigenen Browser-Cache löscht. Caches werden nicht zurückgesetzt, wenn Sie eine neue Version der Anwendung bereitstellen. Falls Sie also jemals vorhaben, eine statische Datei zu ändern, sollte diese eine kurze Ablaufzeit von weniger als einer Stunde haben. In der Regel kann die Standardablaufzeit von 10 Minuten übernommen werden.

Sie können die Standardablaufzeit für alle statischen Datei- und Verzeichnis-Handler ändern. Geben Sie dazu in Ihrer Datei app.yaml das Element default_expiration an. Zum Festlegen bestimmter Ablaufzeiten für einzelne Handler legen Sie das Element expiration innerhalb des Handler-Elements in Ihrer Datei app.yaml fest.

Der Wert, den Sie für die Ablaufzeit der Elemente angeben, wird zum Festlegen der HTTP-Antwortheader Cache-Control und Expires verwendet.

Anwendungs-Caching

Ähnlich wie eine eigenständige Python-Anwendung, die ein Modul auch dann nur einmal lädt, wenn es von mehreren Dateien importiert wird, speichert die Python-Laufzeitumgebung importierte Module zwischen Anfragen auf einem einzelnen Webserver im Cache. Da es sich bei WSGI-Handlern um Module handelt, werden sie zwischen Anfragen im Cache gespeichert. CGI-Handler-Skripts werden nur im Cache gespeichert, wenn sie die Routine main() bereitstellen. Andernfalls wird das CGI-Handler-Skript für jede Anfrage geladen.

Durch das Anwendungs-Caching werden Antwortzeiten erheblich verkürzt. Wir empfehlen die Verwendung der Routine "main()" für alle CGI-Handler-Skripts gemäß der nachfolgenden Beschreibung.

Importe werden im Cache gespeichert

Zur Steigerung der Effizienz bewahrt der Webserver importierte Module im Speicher auf und lädt bzw. evaluiert sie nicht noch einmal, wenn später Anfragen an dieselbe Anwendung auf demselben Server erfolgen. Die meisten Module initialisieren keine globalen Daten und haben auch keine anderen Nebeneffekte, wenn sie importiert werden. Daher ändert sich das Verhalten der Anwendung nicht, wenn diese im Cache gespeichert werden.

Wenn Ihre Anwendung ein Modul importiert, das für jede Anfrage evaluiert werden muss, muss die Anwendung dieses Caching-Verhalten berücksichtigen.

CGI-Handler im Cache speichern

Sie können App Engine anweisen, zusätzlich zu den importierten Modulen das CGI-Handler-Skript selbst im Cache zu speichern. Wenn das Handler-Skript eine Funktion namens main() definiert, werden das Skript und seine globale Umgebung wie ein importiertes Modul im Cache gespeichert. Durch die erste Anfrage an das Skript auf einem gegebenen Webserver wird das Skript normal evaluiert. Bei nachfolgenden Anfragen ruft App Engine die Funktion main() in der im Cache gespeicherten Umgebung auf.

Wenn das Handler-Skript im Cache gespeichert werden soll, muss App Engine in der Lage sein, main() ohne Argumente aufzurufen. Wenn das Handler-Skript die Funktion main() nicht definiert oder die Funktion main() Argumente benötigt (die keine Standardwerte haben), lädt App Engine das gesamte Skript für jede Anfrage und wertet es aus.

Das Speichern des geparsten Python-Codes spart Zeit und es können schneller Antworten zurückgegeben werden. Das Speichern der globalen Umgebung im Cache bietet aber noch weitere potenzielle Verwendungsmöglichkeiten:

  • Kompilierte reguläre Ausdrücke. Alle regulären Ausdrücke werden geparst und in kompilierter Form gespeichert. Sie können kompilierte reguläre Ausdrücke in globalen Variablen speichern und die kompilierten Objekte mithilfe von Anwendungs-Caching zwischen Anfragen wiederholt verwenden.

  • GqlQuery-Objekte: Der GQL-Abfragestring wird zum Zeitpunkt der Erstellung des GqlQuery-Objekts geparst. Die wiederholte Verwendung eines GqlQuery-Objekts mit Parameterbindung und der Methode bind () ist schneller, als das Objekt jedes Mal neu zu konstruieren. Sie können ein GqlQuery-Objekt mit Parameterbindung für die Werte in einer globalen Variablen speichern und es anschließend durch Binden neuer Parameterwerte für jede Anfrage wiederverwenden.

  • Konfiguration und Datendateien: Falls Ihre Anwendung Konfigurationsdaten aus einer Datei lädt und parst, kann sie die geparsten Daten im Speicher behalten, damit die Datei nicht bei jeder Anfrage neu geladen werden muss.

Das Handler-Skript sollte beim Importieren die Funktion main() aufrufen. App Engine erwartet, dass beim Importieren des Skripts die Funktion main() aufgerufen wird. Deshalb ruft App Engine die Funktion beim ersten Laden des Anfrage-Handlers auf einem Server nicht auf.

Das Anwendungs-Caching mit main() bietet eine deutliche Verbesserung der Reaktionszeit Ihres CGI-Handlers. Wir empfehlen es für alle Anwendungen, die CGI verwenden.

Logging

Der App Engine-Webserver erfasst alle Daten, die vom Verarbeitungsskript in den Standard-Ausgabestream geschrieben werden (für die Antwort auf die Webanfrage). Außerdem werden alle Daten, die das Verarbeitungsskript in den Standard-Fehlerstream schreibt, erfasst und als Logdaten gespeichert. Jeder Anfrage wird eine request_id zugewiesen, eine global eindeutige Kennung, die auf der Startzeit der Anfrage basiert. Die Logdaten für Ihre Anwendung können Sie in der Google Cloud Console über Cloud Logging einsehen.

Die Python-Laufzeitumgebung von App Engine enthält spezielle Unterstützung für das Logging-Modul aus der Python-Standardbibliothek, um Logging-Konzepte wie Logging-Ebenen ("debug", "info", "warning", "error", "critical") zu verstehen.

import logging

import webapp2


class MainPage(webapp2.RequestHandler):
    def get(self):
        logging.debug("This is a debug message")
        logging.info("This is an info message")
        logging.warning("This is a warning message")
        logging.error("This is an error message")
        logging.critical("This is a critical message")

        try:
            raise ValueError("This is a sample value error.")
        except ValueError:
            logging.exception("A example exception log.")

        self.response.out.write("Logging example.")


app = webapp2.WSGIApplication([("/", MainPage)], debug=True)

Umgebung

Die Ausführungsumgebung legt automatisch mehrere Umgebungsvariablen fest. Sie können weitere in app.yaml festlegen. Einige der automatisch festgelegten Variablen gelten speziell für App Engine und andere sind Bestandteil des WSGI- oder CGI-Standards. Python-Code kann über das Wörterbuch os.environ auf diese Variablen zugreifen.

Die folgenden Umgebungsvariablen gelten speziell für App Engine:

  • CURRENT_VERSION_ID: Die Haupt- und Nebenversion der aktuell ausgeführten Anwendung im Format "X.Y". Die Hauptversionsnummer ("X") ist in der app.yaml-Datei der Anwendung angegeben. Die Nebenversionsnummer ("Y") wird beim Hochladen der einzelnen Versionen der Anwendung in App Engine automatisch festgelegt. Auf dem Entwicklungs-Webserver ist die Nebenversion immer "1".

  • AUTH_DOMAIN: Die Domain, die zum Authentifizieren von Nutzern mit der Users API verwendet wird. Auf appspot.com gehostete Anwendungen haben eine AUTH_DOMAIN von gmail.com und akzeptieren jedes Google-Konto. Die AUTH_DOMAIN von Anwendungen, die auf einer benutzerdefinierten Domain gehostet werden, entspricht derjenigen der benutzerdefinierten Domain.

  • INSTANCE_ID: Enthält die Instanz-ID der Frontend-Instanz, die eine Anfrage verarbeitet. Die ID ist ein Hexadezimalstring (z. B. 00c61b117c7f7fd0ce9e1325a04b8f0df30deaaf). Ein angemeldeter Administrator kann die ID in einer URL verwenden: https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com Die Anfrage wird an diese bestimmte Frontend-Instanz weitergeleitet. Wenn die Instanz die Anfrage nicht verarbeiten kann, wird sofort der Fehler 503 zurückgegeben.

Die folgenden Umgebungsvariablen sind Bestandteil der WSGI- und CGI-Standards, die ein besonderes Verhalten in App Engine zeigen:

  • SERVER_SOFTWARE: Im Entwicklungs-Webserver lautet dieser Wert "Development/X.Y", wobei "X.Y" die Version der Laufzeit ist. In App Engine lautet dieser Wert "Google App Engine/X.Y.Z".

Zusätzliche Umgebungsvariablen werden nach dem WSGI- oder CGI-Standard festgelegt. Weitere Informationen zu diesen Variablen finden Sie im WSGI-Standard bzw. im CGI-Standard.

Sie können Umgebungsvariablen auch in der app.yaml-Datei festlegen:

env_variables:
  DJANGO_SETTINGS_MODULE: 'myapp.settings'

Der folgende webapp2-Anfrage-Handler zeigt jede Umgebungsvariable an, die für die Anwendung im Browser sichtbar ist:

class PrintEnvironmentHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        for key, value in os.environ.iteritems():
            self.response.out.write("{} = {}\n".format(key, value))

Anfrage-IDs

Beim Senden der Anfrage kann die eindeutige Anfrage-ID gespeichert werden. Sie können die Anfrage-ID später verwenden, um die Logs für diese Anfrage in Cloud Logging abzurufen.

Das folgende Codebeispiel zeigt, wie die Anfrage-ID im Kontext einer Anfrage abgerufen wird:

class RequestIdHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        request_id = os.environ.get("REQUEST_LOG_ID")
        self.response.write("REQUEST_LOG_ID={}".format(request_id))

HTTPS-Verbindungen erzwingen

Aus Sicherheitsgründen sollten alle Anwendungen von Clients eine Verbindung über https anfordern. Um den Browser anzuweisen, für eine bestimmte Seite oder für die gesamte Domain https statt http zu verwenden, legen Sie in Ihren Antworten den Header Strict-Transport-Security fest. Beispiel:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Zum Festlegen dieses Headers für statische Inhalte, die von Ihrer Anwendung bereitgestellt werden, fügen Sie den Header den statischen Datei- und Verzeichnis-Handlern Ihrer Anwendung hinzu.

Verwenden Sie das Paket flask-talisman, um diesen Header für Antworten festzulegen, die aus dem Code generiert werden.

Umgang mit asynchronen Hintergrundarbeiten

Als Hintergrundarbeiten werden alle Arbeiten bezeichnet, die Ihre Anwendung für eine Anfrage ausführt, nachdem Sie Ihre HTTP-Antwort gesendet haben. Führen Sie keine Hintergrundarbeiten in der Anwendung aus und prüfen Sie den Code, um sicherzustellen, dass alle asynchronen Vorgänge abgeschlossen sind, bevor Sie eine Antwort übermitteln.

Für Jobs mit langer Ausführungszeit empfehlen wir die Verwendung von Cloud Tasks. Bei Cloud Tasks sind HTTP-Anfragen langlebig und geben eine Antwort erst zurück, wenn eine asynchrone Arbeit beendet wird.