Recupero URL per i servizi in bundle legacy

Questa pagina descrive il modo in cui 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 dalla tua applicazione App Engine, consulta Invio di richieste HTTP(S).

Richieste

Nel runtime Java 8 di App Engine, puoi utilizzare la classe astratta java.net.URLConnection e le classi correlate della libreria standard Java per stabilire connessioni HTTP e HTTPS dalla tua applicazione Java.

In alternativa, puoi utilizzare anche l'API URL Fetch di App Engine, 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 Vantaggi dell'utilizzo di chiamate Java standard e non di URL Fetch in Java 8.

Protocolli di richiesta

Un'applicazione può recuperare un URL utilizzando HTTP o HTTPS. Il protocollo da utilizzare viene dedotto esaminando 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 è menzionata nell'URL, è implicita nel protocollo. Le richieste HTTP vengono eseguite sulla porta 80 e le richieste HTTPS sulla porta 443.

Metodi di richiesta

Se invii richieste tramite la classe Java standard java.net.URLConnection, puoi utilizzare qualsiasi metodo HTTP supportato.

Se invii richieste tramite il servizio di recupero URL, puoi utilizzare uno 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.

Richiesta di proxy

Tieni presente che il servizio URL Fetch utilizza un proxy conforme a HTTP/1.1 per recuperare il risultato.

Per impedire a un'applicazione di causare una ricorsione infinita di richieste, un gestore delle richieste non può recuperare il proprio URL. È comunque possibile causare una ricorsione infinita con altri mezzi, quindi fai attenzione se la tua applicazione può essere utilizzata per recuperare richieste per URL forniti dall'utente.

Intestazioni delle richieste

La tua applicazione può impostare le intestazioni HTTP per la richiesta in uscita.

Quando invii una richiesta POST HTTP, se un'intestazione Content-Type non è impostata in modo esplicito, l'intestazione viene impostata su x-www-form-urlencoded. Questo è il 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 vengono impostate su valori accurati da App Engine in base alle esigenze. Ad esempio, App Engine calcola l'intestazione Content-Length 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 di App Engine. La stringa aggiunta ha il formato "AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", dove APPID è l'identificatore della tua app.
• X-Appengine-Inbound-Appid. Questa intestazione non può essere modificata e viene aggiunta automaticamente se la richiesta viene inviata tramite il servizio URL Fetch quando il parametro di reindirizzamento è impostato su False.

Timeout delle richieste

Puoi impostare una scadenza o un timeout per una richiesta. Per impostazione predefinita, il timeout per una richiesta è di 10 secondi. Il termine massimo è di 60 secondi per le richieste HTTP(S) e di 60 secondi per le richieste di Task Queue e dei job cron. Quando utilizzi la classe astratta URLConnection con URL Fetch, il servizio utilizza il timeout di connessione (setConnectTimeout()) più il timeout di lettura (setReadTimeout()) come scadenza.

Puoi inviare richieste sincrone e asincrone. Il seguente comportamento si applica all'API URL Fetch:

• Richieste sincrone: la chiamata di recupero attende che l'host remoto restituisca un risultato, quindi restituisce il controllo all'applicazione. Se il tempo di attesa massimo per la chiamata di recupero viene superato, la chiamata genera un'eccezione.
• Richieste asincrone: il servizio di recupero URL avvia la richiesta, poi 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 alcune richieste di recupero URL sono in attesa quando il gestore delle richieste esce, il server delle applicazioni attende che tutte le richieste rimanenti vengano restituite o raggiungano la scadenza prima di restituire una risposta all'utente.

Connessioni sicure e HTTPS

La tua applicazione può recuperare un URL in modo sicuro utilizzando HTTPS per connettersi a server sicuri. I dati di richiesta e risposta vengono trasmessi sulla rete in forma criptata.

Per impostazione predefinita, il proxy URL Fetch convalida l'host che contatta. Questo comportamento consente all'API di rilevare attacchi man-in-the-middle tra App Engine e l'host remoto quando si utilizza HTTPS.

Risposte

Se utilizzi l'API URL Fetch, tieni presente che il servizio di recupero URL restituisce tutti i dati di risposta, inclusi risposta, codice, intestazioni e corpo.

Per impostazione predefinita, se il servizio di recupero URL riceve una risposta con un codice di reindirizzamento, il servizio seguirà il reindirizzamento. Il servizio seguirà fino a cinque risposte di reindirizzamento, quindi restituirà la risorsa finale. Puoi chiedere al servizio URL Fetch di non seguire i reindirizzamenti e restituire invece una risposta di reindirizzamento all'applicazione.

Utilizzo di URL Fetch sul server di sviluppo

Quando l'applicazione è in esecuzione sul server di sviluppo App Engine sul tuo computer, le chiamate al servizio URL Fetch vengono gestite localmente. Il server di sviluppo recupera gli URL contattando direttamente gli host remoti dal tuo computer, utilizzando la configurazione di rete che il computer utilizza per accedere a internet.

Quando testi le funzionalità dell'applicazione che recuperano gli URL, assicurati che il computer possa accedere agli host remoti.

Quote e limiti per il recupero degli URL

Per il runtime Java, puoi utilizzare l'API Java java.net.URLConnection standard, anziché URLFetch, dove queste considerazioni su quota e limiti non si applicano.

Per informazioni sulle quote del servizio URL Fetch, consulta Quote. Per visualizzare l'utilizzo attuale della quota della tua applicazione, vai alla pagina Dettagli quota nella consoleGoogle Cloud .

Vai alla pagina Dettagli quota

Inoltre, all'utilizzo del servizio URL Fetch si applicano i seguenti limiti:

Limite	Importo
Dimensioni richiesta	10 megabyte
Dimensioni dell'intestazione della richiesta	16 KB (tieni presente che questo limite la lunghezza massima dell'URL che può essere specificato nell'intestazione)
Dimensioni risposta	32 megabyte
Scadenza massima (gestore delle richieste)	60 secondi
Scadenza massima (gestore di code di attività e cron job)	60 secondi

Passaggi successivi

Esegui esempi di codice e ricevi indicazioni su come inviare richieste dalla tua applicazione in Invio di richieste HTTP(S).