In questa pagina viene descritto come le applicazioni App Engine emettono richieste HTTP e HTTPS e ricevono risposte. Per visualizzare esempi di codice che mostrano come inviare richieste HTTP e HTTPS dall'applicazione App Engine, consulta Emissione di richieste HTTP(S).
Richieste
Nel runtime Java 8 di App Engine, puoi utilizzare la classe astrattajava.net.URLConnection
e le relative classi dalla libreria standard Java, per creare connessioni HTTP e HTTPS dalla tua applicazione Java.
In alternativa, puoi utilizzare anche l'API App Engine URL Fetch, che fornisce un'implementazione dei metodi definiti in URLConnection
utilizzando l'API URL Fetch. Per informazioni sull'utilizzo delle classi Java native rispetto all'API URL Fetch, consulta la pagina Vantaggi dell'utilizzo delle chiamate Java standard e del non recupero degli URL in Java 8.
Protocolli di richiesta
Un'applicazione può recuperare un URL tramite HTTP o HTTPS. Il protocollo che deve essere utilizzato viene dedotto osservando il protocollo nell'URL di destinazione.
L'URL da recuperare può utilizzare qualsiasi numero di porta nei seguenti intervalli:
80
-90
440
-450
1024
-65535
.
Se la porta non è indicata nell'URL, significa che è implicita dal protocollo. Le richieste HTTP si verificano sulla porta 80
, mentre le richieste HTTPS si verificano sulla porta 443
.
Metodi di richiesta
Se invii le richieste tramite la classe Javajava.net.URLConnection
standard, puoi utilizzare qualsiasi metodo HTTP supportato.
Se invii le richieste tramite il servizio di recupero URL, puoi utilizzare uno qualsiasi dei seguenti metodi HTTP:
GET
POST
PUT
HEAD
DELETE
PATCH
Una richiesta può includere intestazioni HTTP e, per le richieste POST
, PUT
e PATCH
, un payload.
Richiedi proxy
Tieni presente che il servizio di recupero URL utilizza un proxy compatibile con HTTP/1.1 per recuperare il risultato.
Per impedire a un'applicazione di causare una ricorsione infinita delle richieste, un gestore di richieste non può recuperare il proprio URL. È comunque possibile causare una ricorsione infinita con altri mezzi, quindi presta attenzione se la tua applicazione può essere effettuata per recuperare richieste per gli URL forniti dall'utente.
Intestazioni delle richieste
L'applicazione può impostare intestazioni HTTP per la richiesta in uscita.
Quando invii una richiesta HTTP POST
, se un'intestazione Content-Type
non è impostata in modo esplicito, l'intestazione viene impostata su x-www-form-urlencoded
.
Si tratta del tipo di contenuti utilizzato dai moduli web.
Per motivi di sicurezza, le seguenti intestazioni non possono essere modificate dall'applicazione:
Content-Length
Host
Vary
Via
X-Appengine-Inbound-Appid
X-Forwarded-For
X-ProxyUser-IP
Queste intestazioni sono impostate su valori accurati da App Engine in base ai casi. Ad esempio, App Engine calcola l'intestazione Content-Length
a partire dai dati della richiesta e la aggiunge alla richiesta prima dell'invio.
Le seguenti intestazioni indicano l'ID applicazione dell'app richiedente:
User-Agent
. Questa intestazione può essere modificata, ma App Engine aggiungerà una stringa identificatore per consentire ai server di identificare le richieste App Engine. La stringa aggiunta ha il formato"AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)"
, doveAPPID
è l'identificatore dell'app.X-Appengine-Inbound-Appid
. Questa intestazione non può essere modificata e viene aggiunta automaticamente se la richiesta viene inviata tramite il servizio di recupero URL quando il parametro dei reindirizzamenti successivi è impostato suFalse
.
Timeout delle richieste
Puoi impostare una scadenza o un timeout per una richiesta. Per impostazione predefinita, il timeout per una richiesta è di 10 secondi.
La scadenza massima è di 60 secondi per le richieste HTTP(S) e di 60 secondi per le richieste della coda di attività e del cron job.
Quando utilizzi la classe astratta URLConnection
con Recupero URL, il servizio utilizza il timeout della connessione (setConnectTimeout()
) più il timeout di lettura (setReadTimeout()
) come scadenza.
Puoi inviare richieste sincrone e asincrone. All'API URL Fetch si applica il seguente comportamento:
- Richieste sincrone: la chiamata di recupero attende che l'host remoto non restituisca un risultato, quindi restituisce il controllo all'applicazione. Se viene superato il tempo di attesa massimo per la chiamata di recupero, la chiamata genera un'eccezione.
- Richieste asincrone: il servizio di recupero URL avvia la richiesta, quindi restituisce immediatamente un oggetto. L'applicazione può eseguire altre attività durante il recupero dell'URL. Quando l'applicazione ha bisogno dei risultati, chiama un metodo sull'oggetto, che attende il completamento della richiesta, se necessario, quindi restituisce il risultato. Se una qualsiasi richiesta di recupero URL è in attesa quando il gestore di richieste esce, l'application server attende che tutte le richieste rimanenti vengano restituite o raggiungano la scadenza prima di restituire una risposta all'utente.
Connessioni sicure e HTTPS
L'applicazione può recuperare un URL in modo sicuro utilizzando HTTPS per connettersi a server protetti. I dati delle richieste e delle risposte vengono trasmessi sulla rete in formato criptato.
Se utilizzi l'API URL Fetch, tieni presente che il proxy di recupero URL non convalida l'host che sta contattando. Il server proxy non è in grado di rilevare attacchi man in the middle tra App Engine e l'host remoto quando viene utilizzato HTTPS.
Puoi utilizzare la classe FetchOptions
nell'API URLFetchService
per abilitare la convalida dell'host.
Risposte
Se utilizzi l'API URL Fetch, tieni presente che il servizio restituisce tutti i dati delle risposte, inclusi risposta, codice, intestazioni e corpo.
Per impostazione predefinita, se il servizio di recupero URL riceve una risposta con un codice di reindirizzamento, segue il reindirizzamento. Il servizio seguirà fino a cinque risposte di reindirizzamento, quindi restituirà la risorsa finale. Puoi indicare al servizio di recupero URL di non seguire i reindirizzamenti e restituire invece una risposta di reindirizzamento all'applicazione.
Utilizzo del recupero URL sul server di sviluppo
Quando l'applicazione è in esecuzione sul server di sviluppo App Engine sul tuo computer, le chiamate al servizio di recupero URL vengono gestite localmente. Il server di sviluppo recupera gli URL contattando gli host remoti direttamente dal computer, utilizzando la configurazione di rete utilizzata dal computer per accedere a Internet.
Quando testi le funzionalità della tua applicazione che recuperano gli URL, assicurati che il tuo computer possa accedere agli host remoti.
Quote e limiti per il recupero degli URL
Per il runtime Java, puoi utilizzare l'API Javajava.net.URLConnection
standard al posto di URLFetch, in cui queste considerazioni relative a quota e limiti non si applicano.
Per informazioni sulle quote di servizio di recupero URL, consulta Quote. Per visualizzare l'utilizzo attuale delle quote della tua applicazione, vai alla pagina Dettagli quota nella console Google Cloud.
Vai alla pagina dei dettagli della quota
Inoltre, per l'utilizzo del servizio URL Fetch si applicano i seguenti limiti:
Limite | Importo |
---|---|
Dimensioni richiesta | 10 megabyte |
Dimensioni intestazione richiesta | 16 kB (tieni presente che limita la lunghezza massima dell'URL che può essere specificato nell'intestazione) |
Dimensioni risposta | 32 megabyte |
Scadenza massima (gestore delle richieste) | 60 secondi |
Scadenza massima (coda di attività e gestore di cron job) | 60 secondi |
Passaggi successivi
Esegui esempi di codice e ottieni indicazioni su come inviare richieste dalla tua applicazione nella sezione Inviare richieste HTTP(S).