Questa pagina descrive come le applicazioni App Engine utilizzano il servizio di recupero URL per emettere richieste HTTP e HTTPS e ricevere 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
App Engine utilizza il servizio di recupero URL per emettere richieste in uscita. Il linguaggio PHP fornisce diverse funzioni per effettuare richieste HTTP remote. Questi sono implementati in modi diversi in App Engine e sono soggetti a quote e costi diversi. Per ulteriori informazioni sui diversi tipi, consulta Emissione di richieste HTTP(S).Protocolli di richiesta
Un'applicazione può recuperare un URL utilizzando HTTP o HTTPS. Il protocollo da utilizzare viene dedotto dal protocollo nell'URL di destinazione.
L'URL da recuperare può utilizzare qualsiasi numero di porta nei seguenti intervalli:
80-90440-4501024-65535.
Se la porta non è indicata 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 il servizio di recupero URL, puoi utilizzare uno dei seguenti metodi HTTP:
GETPOSTPUTHEADDELETEPATCH
Una richiesta può includere intestazioni HTTP e, per le richieste POST, PUT e PATCH, un payload.
Proxy delle richieste
Tieni presente che il servizio di recupero dell'URL 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 è autorizzato a recuperare il proprio URL. È comunque possibile causare una ricorsione infinita con altri mezzi, quindi fai attenzione se la tua applicazione può essere impostata per recuperare richieste per URL forniti dall'utente.
Intestazioni delle richieste
L'applicazione può impostare le intestazioni HTTP per la richiesta in uscita.
Quando invii una richiesta POST HTTP, se un'intestazione Content-Type non viene impostata esplicitamente, 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-LengthHostVaryViaX-Appengine-Inbound-AppidX-Forwarded-ForX-ProxyUser-IP
App Engine imposta questi valori su valori accurati, se opportuno. Ad esempio, App Engine calcola l'Content-Length intestazione 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 di 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)", doveAPPIDè 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 di recupero dell'URL quando il parametro di reindirizzamento seguito è 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 di coda di attività e di job cron.
Connessioni sicure e HTTPS
L'applicazione può recuperare un URL in modo sicuro utilizzando HTTPS per connettersi a server sicuri. I dati delle richieste e delle risposte vengono trasmessi sulla rete in forma criptata.
Nell'API PHP, il proxy Fetch dell'URL convalida l'host con cui sta contattando per impostazione predefinita. Questo comportamento consente all'API di rilevare gli 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 URL Fetch restituisce tutti i dati di risposta, inclusi la risposta, il codice, le intestazioni e il 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 istruire il servizio di recupero dell'URL a non seguire i reindirizzamenti e restituire invece una risposta di reindirizzamento all'applicazione.
Se la risposta in arrivo supera il limite di dimensione massima della risposta, il servizio di recupero URL la tronca automaticamente. Per maggiori dettagli, consulta la sezione Quote e limiti.
Utilizzare 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 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 dell'URL
Per informazioni sulle quote del servizio di recupero dell'URL, consulta Quote. Per visualizzare l'utilizzo attuale della quota della tua applicazione, vai alla pagina Dettagli quota in Google Cloud Console.
Vai alla pagina Dettagli quota
Inoltre, all'utilizzo del servizio di recupero dell'URL si applicano i seguenti limiti:
| Limite | Importo |
|---|---|
| Dimensioni richiesta | 10 megabyte |
| Dimensioni dell'intestazione della richiesta | 16 KB (tieni presente che questo limita la lunghezza massima dell'URL che può essere specificato nell'intestazione) |
| Dimensioni risposta | 32 megabyte |
| Scadenza massima (gestori delle richieste) | 60 secondi |
| Scadenza massima (Task Queue e gestore dei 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).