Auf dieser Seite wird beschrieben, wie App Engine-Anwendungen HTTP- und HTTPS-Anfragen senden und Antworten empfangen. Codebeispiele zum Senden von HTTP- und HTTPS-Anfragen über die App Engine-Anwendung finden Sie unter HTTP(S)-Anfragen senden.
Anfragen
In der Java 8-Laufzeit von App Engine können Sie die abstrakte Klassejava.net.URLConnection
und verwandte Klassen aus der Java-Standardbibliothek verwenden, um von einer Java-Anwendung aus HTTP- und HTTPS-Verbindungen herzustellen.
Alternativ können Sie die App Engine URL Fetch API verwenden, die eine Implementierung der in URLConnection
definierten Methoden mithilfe der URL Fetch API bereitstellt. Informationen zur Verwendung der nativen Java-Klassen im Vergleich zur URL Fetch API finden Sie unter Vorteile von Java-Standardaufrufen gegenüber URL-Abrufen in Java 8.
Anfrageprotokolle
Zum Abrufen einer URL kann eine Anwendung HTTP oder HTTPS verwenden. Das zu verwendende Protokoll wird abgeleitet, indem das Protokoll in der Ziel-URL untersucht wird.
Die abzurufende URL kann innerhalb der folgenden Bereiche eine beliebige Portnummer verwenden:
80
–90
440
–450
1024
-65535
.
Wenn der Port in der URL nicht angegeben ist, wird er durch das Protokoll impliziert. HTTP-Anfragen werden über Port 80
und HTTPS-Anfragen über Port 443
gesendet.
Anfragemethoden
Wenn Sie Anfragen über die Java-Standardklassejava.net.URLConnection
senden, können Sie jede beliebige unterstützte HTTP-Methode verwenden.Anfragen, die mithilfe des URL-Abrufdienstes gesendet werden, können eine der folgenden HTTP-Methoden verwenden:
GET
POST
PUT
HEAD
DELETE
PATCH
Eine Anfrage kann HTTP-Header und im Fall von POST
-, PUT
- und PATCH
-Anfragen eine Nutzlast enthalten.
Anfrage-Proxys
Der URL-Abrufdienst verwendet zum Abrufen von Ergebnissen einen HTTP/1.1-konformen Proxy.
Anfrage-Handler können ihre eigene URL nicht abrufen. Auf diese Weise wird verhindert, dass eine Anwendung endlos wiederkehrende Anfragen verursacht. Solche endlos wiederkehrenden Anfragen können jedoch auch auf andere Weise verursacht werden. Sie sollten daher vorsichtig sein, wenn Ihre Anwendung URL-Anfragen abrufen kann, die vom Nutzer bereitgestellt worden sind.
Anfrageheader
Sie können in Ihrer Anwendung HTTP-Header für die ausgehende Anfrage festlegen.
Wenn beim Senden einer HTTP-POST
-Anfrage ein Content-Type
-Header nicht explizit festgelegt wird, wird der Header auf x-www-form-urlencoded
gesetzt.
Dies ist der für Webformulare verwendete Inhaltstyp.
Aus Sicherheitsgründen können die folgenden Header von der Anwendung nicht geändert werden:
Content-Length
Host
Vary
Via
X-Appengine-Inbound-Appid
X-Forwarded-For
X-ProxyUser-IP
Für diese Header legt App Engine nach Bedarf genaue Werte fest. Beispielsweise berechnet App Engine den Content-Length
-Header aus den Anfragedaten und fügt ihn der Anfrage vor dem Senden hinzu.
Die folgenden Header geben die Anwendungs-ID der anfragenden Anwendung an:
User-Agent
. Dieser Header kann geändert werden. App Engine fügt jedoch einen ID-String an, damit App Engine-Anfragen von Servern identifiziert werden können. Der angefügte String hat das Format"AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)"
, wobeiAPPID
die ID Ihrer Anwendung ist.X-Appengine-Inbound-Appid
. Dieser Header kann nicht geändert werden und wird automatisch hinzugefügt, falls die Anfrage über den URL-Abrufdienst gesendet wird, wenn der Parameter für Weiterleitungen aufFalse
eingestellt ist.
Zeitlimits für Anfragen
Sie können eine Frist bzw. ein Zeitlimit für eine Anfrage festlegen. Standardmäßig beträgt das Zeitlimit für eine Anfrage 10 Sekunden.
Die maximale Frist beträgt 60 Sekunden für HTTP(S)-Anfragen und 60 Sekunden für Aufgabenwarteschlangen- und Cronjob-Anfragen.
Bei Verwendung der abstrakten Klasse URLConnection
mit URL-Abruf verwendet der Dienst das Verbindungszeitlimit (setConnectTimeout()
) plus das Lesezeitlimit (setReadTimeout()
) als Frist.
Es werden sowohl synchrone als auch asynchrone Anfragen unterstützt. Das folgende Verhalten gilt für die URL Fetch API:
- Synchrone Anfragen: Der Abrufaufruf wartet, bis der Remotehost ein Ergebnis zurückgibt, und gibt dann die Steuerung an die Anwendung zurück. Wenn die maximale Wartezeit für den Abrufaufruf überschritten wird, löst der Aufruf eine Ausnahme aus.
- Asynchrone Anfragen: Der URL-Abrufdienst sendet die Anfrage und gibt dann sofort ein Objekt zurück. Während die URL abgerufen wird, kann die Anwendung andere Aufgaben ausführen. Wenn die Anwendung die Ergebnisse benötigt, ruft sie im Objekt eine Methode auf. Falls notwendig, wartet das Objekt, bis die Anfrage abgeschlossen ist. Anschließend wird das Ergebnis zurückgegeben. Wenn beim Beenden des Anfrage-Handlers noch Anfragen für URL-Abrufe ausstehen, wartet der Anwendungsserver, bis die verbleibenden Anfragen entweder verarbeitet werden oder ihre Frist abgelaufen ist. Erst dann wird dem Nutzer eine Antwort zurückgegeben.
Sichere Verbindungen und HTTPS
Zum sicheren Abrufen einer URL können Sie HTTPS verwenden, um Ihre Anwendung mit sicheren Servern zu verbinden. Anfrage- und Antwortdaten werden verschlüsselt über das Netzwerk übertragen.
Wenn Sie die URL Fetch API verwenden, wird der kontaktierte Host nicht vom URL-Abrufproxy validiert. Der Proxyserver kann beim Verwenden von HTTPS keine Man-in-the-Middle-Angriffe zwischen App Engine und dem Remote-Host erkennen.
Sie können die Klasse FetchOptions
in der URLFetchService
API verwenden, um die Hostvalidierung zu aktivieren.
Antworten
Wenn Sie die URL-Abruf-API verwenden, gibt der URL-Abrufdienst alle Antwortdaten zurück, einschließlich Antwortcode, -header und -text.
Standardmäßig folgt der URL-Abrufdienst einer Weiterleitung, wenn er eine Antwort mit einem Weiterleitungscode erhält. Der Dienst folgt bis zu fünf Weiterleitungsantworten und gibt dann die endgültige Ressource zurück. Sie können den URL-Abrufdienst anweisen, Weiterleitungen nicht zu folgen, sondern stattdessen eine Weiterleitungsantwort an die Anwendung zurückzugeben.
URL-Abrufdienst auf dem Entwicklungsserver verwenden
Wenn die Anwendung auf dem App Engine-Entwicklungsserver auf Ihrem Computer ausgeführt wird, werden Aufrufe an den URL-Abrufdienst lokal verarbeitet. Der Entwicklungsserver ruft URLs ab, indem er Remote-Hosts direkt über den Computer kontaktiert. Dazu wird die Netzwerkkonfiguration verwendet, mit der der Computer auf das Internet zugreift.
Achten Sie darauf, dass der Computer auf die Remote-Hosts zugreifen kann, wenn Sie die Features Ihrer Anwendung testen, mit denen URLs abgerufen werden.
Kontingente und Limits für den URL-Abruf
Für die Java-Laufzeit können Sie die standardmäßige Javajava.net.URLConnection
API anstelle des URL-Abrufs verwenden, wo diese Hinweise zu Kontingenten und Limits nicht gelten.Informationen zu URL-Abrufdienstkontingenten finden Sie unter Kontingente. Die aktuelle Kontingentnutzung Ihrer Anwendung können Sie in der Google Cloud Console auf der Seite „Kontingente“ sehen.
Weiter zur Seite „Kontingente”
Außerdem gelten für die Verwendung des URL-Abrufdienstes die folgenden Beschränkungen:
Limit | Menge |
---|---|
Größe der Anfrage | 10 Megabyte |
Größe des Anfrage-Headers | 16 KB (Hinweis: Hierdurch wird die maximale URL-Länge beschränkt, die im Header angegeben werden kann.) |
Größe der Antwort | 32 Megabyte |
Maximale Frist (Anfrage-Handler) | 60 Sekunden |
Maximale Frist (Aufgabenwarteschlange- und Cronjob-Handler) | 60 Sekunden |
Weitere Informationen
Codebeispiele und weitere Informationen zum Senden von Anfragen aus einer Anwendung finden Sie unter HTTP(S)-Anfragen senden.