Intestazioni di richiesta e risposte

ID regione

REGION_ID è un codice abbreviato che viene assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono essere simili ai codici paese e di provincia di uso comune. Per le app create dopo febbraio 2020, il campo REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

Ottimo

Utilizza questa pagina di riferimento per i dettagli sulle intestazioni HTTP supportate e sui limiti di richieste e risposte in App Engine. Per capire come App Engine riceve le richieste e invia risposte, consulta la sezione Come vengono gestite le richieste.

Intestazioni delle richieste

Una richiesta HTTP in entrata include le intestazioni HTTP inviate dal client. Per motivi di sicurezza, alcune intestazioni vengono igienizzate, modificate o rimosse da proxy intermedi prima che raggiungano l'applicazione.

Intestazioni rimosse dalle richieste in arrivo

Le seguenti intestazioni vengono rimosse dalle richieste in arrivo se vengono inviate da un client:

• Intestazioni con nomi che corrispondono al pattern X-Google-*. Questo pattern del nome è riservato a Google.

• Intestazioni con nomi che corrispondono alle intestazioni specifiche di App Engine. Vengono rimosse solo le corrispondenze esatte (senza distinzione tra maiuscole e minuscole). Ad esempio, le intestazioni denominate X-Appengine-Country o X-AppEngine-Country verranno rimosse, ma non X-Appengine-Cntry.

Inoltre, le seguenti intestazioni sono rimosse dalle richieste in entrata perché riguardano il trasferimento dei dati HTTP tra il client e il server:

• Accept-Encoding
• Connection
• Keep-Alive
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding

Ad esempio, il server potrebbe inviare automaticamente una risposta con gzip a seconda del valore dell'intestazione della richiesta Accept-Encoding. L'applicazione stessa non ha bisogno di sapere quali codifiche dei contenuti sono accettate dal client.

Nota: le intestazioni delle entità (intestazioni correlate al corpo della richiesta) non vengono igienizzate o verificate, pertanto le applicazioni non dovrebbero fare affidamento su di esse. In particolare, l'intestazione della richiesta Content- MD5 viene inviata all'applicazione senza essere modificata, pertanto potrebbe non corrispondere all'hash MD5 dei contenuti. Inoltre, l'intestazione della richiesta Content-Encoding non viene controllata dal server, quindi se il client invia un corpo della richiesta compresso con gzip, verrà inviata in forma compressa all'applicazione.

Richieste e WSGI

Il server determina quale oggetto applicazione Python chiamare da confrontando l'URL della richiesta con i pattern URL nel file di configurazione dell'app. Quindi chiama l'oggetto dell'applicazione utilizzando gli argomenti definiti nello standard WSGI. L'oggetto dell'applicazione esegue le azioni appropriate alla richiesta, quindi prepara una risposta e la restituisce come elenco di stringhe.

La maggior parte delle applicazioni utilizza un framework, come webapp2, per gestire le richieste WSGI. webapp2 è incluso come parte del runtime Python 2.7.

Richieste e CGI

Avviso: la funzionalità CGI è inclusa per compatibilità con le versioni precedenti e il suo utilizzo è sconsigliato. Se possibile, usa WSGI.

Il server determina quale script del gestore Python eseguire rispetto confrontando l'URL della richiesta con i pattern URL nel file di configurazione dell'app. ed esegue lo script in un ambiente popolato con i dati della richiesta. Come descritto nello standard CGI, il server inserisce i dati della richiesta in variabili di ambiente e nel flusso di input standard. Lo script esegue le azioni appropriate alla richiesta, quindi prepara una risposta e la inserisce nel flusso di output standard.

La maggior parte delle applicazioni utilizza una libreria per analizzare le richieste CGI e restituire risposte DOC, come il modulo CGI dalla libreria standard Python o un framework web che conosce il protocollo CGI (come webapp). Per i dettagli sulle variabili di ambiente e sul formato dei dati dei flussi di input, consulta la documentazione in CGI.

Intestazioni specifiche di App Engine

Come servizio per l'app, App Engine aggiunge le seguenti intestazioni a tutte le richieste:

X-Appengine-Country

Paese da cui ha avuto origine la richiesta, sotto forma di codice paese ISO 3166-1 alpha-2. App Engine determina questo codice dall'indirizzo IP del client. Tieni presente che le informazioni sul paese non derivano dal database WHOIS. È possibile che un indirizzo IP con informazioni sul paese nel database WHOIS non abbia informazioni sul paese nell'intestazione X-Appengine-Country. La tua applicazione deve gestire il codice paese speciale ZZ (paese sconosciuto).

X-Appengine-Region

Nome della regione in cui ha avuto origine la richiesta. Questo valore è valido solo nel contesto del paese in X -Appengine-Country. Ad esempio, se il paese è "US" e la regione è "ca", significa "ca" significa "California", non il Canada. L'elenco completo dei valori validi per la regione è disponibile nello standard ISO-3166-2.

X-Appengine-City

Nome della città in cui ha avuto origine la richiesta. Ad esempio, una richiesta proveniente dalla città di Mountain View potrebbe avere il valore di intestazione mountain view. Non esiste un elenco canonico dei valori validi per questa intestazione.

X-Appengine-CityLatLong

Latitudine e longitudine della città da cui ha avuto origine la richiesta. Questa stringa potrebbe avere il seguente aspetto: "37.386051,-122.083851" per una richiesta a Mountain View.

X-Cloud-Trace-Context

Un identificatore univoco per la richiesta utilizzata per Cloud Trace e Cloud Logging. Non esiste un'opzione per disattivare l'intestazione o scegliere la frequenza di campionamento per il tracciamento poiché tutte le app dell'ambiente standard di App Engine vengono tracciate automaticamente.

X-Forwarded-For: [CLIENT_IP(s)], [global forwarding rule IP]

Un elenco di indirizzi IP delimitato da virgole attraverso il quale la richiesta client è stata instradata. Il primo IP in questo elenco è solitamente l'IP del client che ha creato la richiesta. Gli IP successivi forniscono informazioni sui server proxy che hanno gestito anche la richiesta prima che raggiungesse il server delle applicazioni. Ad esempio:

X-Forwarded-For: clientIp, proxy1Ip, proxy2Ip

X-Forwarded-Proto [http | https]

Mostra http o https in base al protocollo utilizzato dal client per la connessione all'applicazione.

Il bilanciatore del carico Google Cloud termina tutte le connessioni https e quindi inoltra il traffico alle istanze App Engine su http. Ad esempio, se un utente richiede l'accesso al tuo sito tramite https://PROJECT_ID.REGION_ID.r.appspot.com, il valore dell'intestazione X-Forwarded-Proto è https.

Inoltre, App Engine può impostare le seguenti intestazioni uso interno da parte di App Engine:

• X-Appengine-Https
• X-Appengine-User-IP
• X-Appengine-Api-Ticket
• X-Appengine-Request-Log-Id
• X-Appengine-Default-Version-Hostname
• X-Appengine-Timeout-Ms

I servizi App Engine possono aggiungere ulteriori intestazioni della richiesta:

• Per i gestori login:admin o login:required specificati in app.yaml, App Engine aggiunge il seguente insieme di intestazioni:

  • X-Appengine-User-Email, con l'intestazione di esempio "[e-mail]"
  • X-Appengine-Auth-Domain,con l'intestazione di esempio "example.com"
  • X-Appengine-User-ID, con intestazione di esempio: "100979712376541954724"
  • X-Appengine-User-Nickname, con l'intestazione di esempio "ange"
  • X-Appengine-User-Organization, con l'intestazione di esempio "example.com"
  • X-Appengine-User-Is-Admin, con l'intestazione di esempio "1"

• Il servizio coda di attività aggiunge intestazioni aggiuntive alle richieste che forniscono dettagli sull'attività nella richiesta e sulla coda a cui è associata.

• Le richieste del servizio Cron aggiungono la seguente intestazione:

  X-Appengine-Cron: true

  Per maggiori dettagli, consulta la pagina Sicurezza degli URL per cron.

• Le richieste provenienti da altre applicazioni App Engine includeranno un'intestazione che identifica l'applicazione che esegue la richiesta, se l'applicazione richiedente utilizza il servizio di recupero URL:

  X-Appengine-Inbound-Appid

  Per ulteriori dettagli, consulta la documentazione di App Identity.

Richiedi risposte

Questa documentazione relativa all'intestazione HTTP si applica solo alle risposte alle richieste HTTP in entrata. La risposta potrebbe essere modificata prima che venga restituita al client. Per le intestazioni HTTP relative alle richieste in uscita create dal codice di App Engine, consulta la documentazione di intestazione per URLFetch.

Intestazioni rimosse

Le seguenti intestazioni vengono ignorate e rimosse dalla risposta:

• Connection
• Content-Encoding*
• Content-Length
• Date
• Keep-Alive
• Proxy-Authenticate
• Server
• Trailer
• Transfer-Encoding
• Upgrade

* Può essere riaggiunto se la risposta è compressa da App Engine.

Vengono rimosse anche le intestazioni che contengono caratteri non ASCII nel nome o nel valore.

Intestazioni aggiunte o sostituite

Le seguenti intestazioni vengono aggiunte o sostituite nella risposta:

Cache-Control, Expires e Vary

Queste intestazioni specificano il criterio di memorizzazione nella cache per i proxy web intermedi (come il Google Frontend e i provider di servizi Internet) e i browser. Se la tua app imposta queste intestazioni di risposta, in genere non vengono modificate, a meno che l'app non imposti anche un'intestazione Set-Cookie o la risposta venga generata per un utente che ha eseguito l'accesso utilizzando un account amministratore.

Se la tua app imposta un'intestazione della risposta Set-Cookie, l'intestazione Cache-Control verrà impostata su private (se non è già più restrittiva) e l'intestazione Expires verrà impostata sulla data corrente (se non è già passata). In genere, questo consente ai browser di memorizzare nella cache la risposta, ma non i server proxy intermedi. Questo avviene per motivi di sicurezza, perché se la risposta è stata memorizzata nella cache pubblicamente, un altro utente potrebbe successivamente richiedere la stessa risorsa e recuperare il cookie del primo utente.

Nota: il server di sviluppo disabilita la memorizzazione nella cache per impostazione predefinita (sia per gli script che per i contenuti statici), quindi se non specifichi intestazioni di memorizzazione nella cache, non avrai contenuti memorizzati nella cache durante lo sviluppo dell'app.

Se utilizzi un framework basato su webob (ad esempio webapp o webapp2), il framework imposta l'intestazione Cache-Control su no-cache per impostazione predefinita, quindi devi sostituirla se vuoi memorizzare la memorizzazione nella cache nei gestori di script.

Se nella tua app non viene impostata l'intestazione della risposta Cache-Control, il server potrebbe impostarla su private e aggiungere un'intestazione Vary: Accept-Encoding.

Per ulteriori informazioni sulla memorizzazione nella cache, incluso l'elenco dei valori Vary supportati da Google Frontend, consulta Memorizzazione nella cache delle risposte.

Content-Encoding

A seconda delle intestazioni e della risposta della richiesta Content-Type, il server potrebbe comprimere automaticamente il corpo della risposta, come descritto sopra. In questo caso, aggiunge un'intestazione Content-Encoding: gzip per indicare che il corpo è compresso. Per maggiori dettagli, consulta la sezione sulla compressione delle risposte.

Content-Length o Transfer-Encoding

Il server ignora sempre l'intestazione Content-Length restituita dall'applicazione. Verrà impostato Content-Length sulla lunghezza del corpo (dopo la compressione, se viene applicata la compressione) oppure verrà eliminato Content-Length e verrà utilizzata la codifica di trasferimento in blocchi (aggiungendo un'intestazione Transfer-Encoding: chunked).

Content-Type

Se non specificato dall'applicazione, il server imposterà un'intestazione Content-Type: text/html predefinita.

Nota: se utilizzi un framework basato su webob (ad esempio webapp o webapp2), l'intestazione Content-Type è impostata su text/html; charset=utf-8 per impostazione predefinita, pertanto questo valore predefinito (senza una proprietà charset) non si applica.

Date

Imposta la data e l'ora correnti.

Server

Imposta su Google Frontend. Il server di sviluppo la imposta su Development/x, dove x è il numero di versione.

Se accedi a pagine dinamiche sul tuo sito dopo aver eseguito l'accesso utilizzando un account amministratore, App Engine include le statistiche per ogni richiesta nelle intestazioni della risposta:

X-Appengine-Resource-Usage

Le risorse utilizzate dalla richiesta, incluso il tempo lato server sotto forma di numero di millisecondi.

Le risposte con statistiche sull'utilizzo delle risorse non saranno memorizzabili nella cache.

Se l'intestazione X-Appengine-BlobKey è nella risposta dell'applicazione, questa e l'intestazione X-Appengine-BlobRange facoltativa verranno utilizzate per sostituire il corpo con tutti o parte dei contenuti del blob di blobstore. Se Content-Type non è specificato dall'applicazione, verrà impostato il tipo MIME del blob. Se viene richiesto un intervallo, lo stato della risposta verrà modificato in 206 Partial Content e verrà aggiunta un'intestazione Content-Range. Le intestazioni X-Appengine-BlobKey e X-Appengine-BlobRange verranno rimosse dalla risposta. In genere, non è necessario impostare queste intestazioni autonomamente, in quanto sono impostate dalla classe blobstore_handlers.BlobstoreDownloadHandler. Per maggiori dettagli, consulta la pagina Pubblicare un blob.

Intestazioni delle risposte impostate nella configurazione dell'applicazione

Le intestazioni delle risposte HTTP personalizzate possono essere impostate per URL per i percorsi dinamici e statici nel file di configurazione dell'applicazione. Per ulteriori dettagli, consulta le sezioni http_headers nella documentazione di configurazione.