Recupero URL per servizi in bundle legacy

Questa pagina descrive come le applicazioni App Engine utilizzare il servizio di recupero URL inviare richieste HTTP e HTTPS e ricevere risposte. Per visualizzare esempi di codice che dimostrano come inviare richieste HTTP e HTTPS dal tuo per l'applicazione App Engine, Emissione di Richieste HTTP(S).

Se disponi configurare l'accesso VPC serverless o se utilizzi l'API Sockets, devono interrompere il recupero degli URL dalla gestione delle richieste. Il recupero URL genera richieste alla tua rete VPC o L'API Sockets ha errori. Dopo aver disabilitato il metodo di recupero URL, la libreria Python standard per gestire le richieste HTTP. Se hai bisogno delle funzionalità fornite da URL Fetch per richieste specifiche, puoi usare la libreria urlfetch direttamente per quelli richieste specifiche.

Questa API è supportata per runtime di prima generazione e può essere utilizzata quando eseguire l'upgrade ai runtime di seconda generazione corrispondenti. Se esegui l'aggiornamento ad App Engine Python 3 runtime, consulta guida alla migrazione per saperne di più sulle opzioni di migrazione per i servizi in bundle legacy.

Richieste

App Engine utilizza il servizio di recupero URL per inviare le richieste in uscita. In Python, puoi utilizzare httplib, urllib e urllib2 per effettuare richieste HTTP. in un'applicazione App Engine, ciascuna libreria eseguirà queste richieste utilizzando il servizio di recupero URL. Puoi utilizzare anche urlfetch direttamente nella libreria.

Protocolli di richiesta

Un'applicazione può recuperare un URL tramite HTTP o HTTPS. Il protocollo viene dedotta 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 è menzionata nell'URL, si riferisce alla porta protocollo. Le richieste HTTP si verificano sulla porta 80 e si verificano le richieste HTTPS sulla porta 443.

Metodi di richiesta

Se invii 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 POST, PUT e PATCH richieste, un payload.

Richiedi proxying

Tieni presente che il servizio di recupero URL utilizza un proxy compatibile con HTTP/1.1 per recuperare il risultato.

Per evitare che un'applicazione causi una ricorrenza infinita di richieste, è necessario gestore di richieste non è autorizzato a recuperare il proprio URL. È ancora che sia possibile causare una ricorrenza infinita con altri mezzi, fai attenzione se è possibile indurre la tua applicazione a recuperare richieste per URL forniti dall'utente.

Intestazioni delle richieste

L'applicazione può impostare intestazioni HTTP per la richiesta in uscita.

Durante l'invio di una richiesta POST HTTP, se un'intestazione Content-Type è non è impostata in modo esplicito, l'intestazione è 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 sono impostate su valori precisi da App Engine appropriato. Ad esempio, App Engine calcola Intestazione Content-Length dei dati della richiesta e la aggiunge a la richiesta prima dell'invio.

Le seguenti intestazioni indicano l'ID applicazione dell'app richiedente:

• User-Agent. Questa intestazione può essere modificata, ma App Engine Aggiungere una stringa identificativo per consentire ai server di identificare l'App del motore di ricerca. La stringa aggiunta ha il formato "AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", dove APPID è l'identificatore dell'app.
• X-Appengine-Inbound-Appid. Questa intestazione non può essere modificata e risulta aggiunta automaticamente se la richiesta viene inviata tramite il metodo di recupero URL servizio quando i seguenti reindirizzamenti è impostato su False.

Timeout delle richieste

Puoi impostare una scadenza, o timeout, per una richiesta. Per impostazione predefinita, per una richiesta è 10 secondi.

Puoi inviare richieste sincrone e richieste asincrone. Le seguenti si applica all'API di recupero URL:

• Richieste sincrone: la chiamata di recupero attende che il telecomando l'host restituisce un risultato, quindi il controllo all'applicazione. Se viene superato il tempo massimo di attesa per la chiamata di recupero, viene restituito l'errore della chiamata genera un'eccezione.
• Richieste asincrone: il servizio di recupero URL avvia la richiesta. e restituisce immediatamente con un oggetto. L'applicazione può eseguire altre attività durante il recupero dell'URL. Quando l'applicazione richiede i risultati, viene chiamato un metodo sull'oggetto, che attende per completare la richiesta, se necessario, quindi restituisce il risultato. Se presente Le richieste di recupero dell'URL sono in attesa quando il gestore di richieste esce, il server delle applicazioni attende che tutte le richieste rimanenti vengano restituite o raggiungere 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 la connessione a server protetti. I dati di richiesta e risposta vengono trasmessi in forma criptata.

Nell'API Python, il proxy di recupero URL non convalida l'host di cui si trova. contatti per impostazione predefinita. Puoi aggiungere un elemento validate_certificate facoltativo all'argomento fetch() per abilitare la convalida dell'host.

Nota: il modulo urllib al momento non fornisce metodi per convalidare gli host.

Risposte

Se utilizzi l'API di recupero URL, tieni presente che il servizio di recupero URL restituisce dati della risposta, tra cui 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 seguite fino a cinque risposte di reindirizzamento, quindi restituiscono la risorsa finale. Puoi indicare al servizio di recupero URL di non seguire i reindirizzamenti e restituiscono invece una risposta di reindirizzamento all'applicazione.

Nota: l'API URL Fetch impone una risposta limiti di dimensione. Se l'email in entrata la risposta supera le dimensioni massime consentite per la risposta limite, il servizio di recupero URL genera un'eccezione. Consulta le Quote e limiti per maggiori dettagli.

Puoi indicare all'API URL Fetch di troncare la risposta anziché sollevare un'eccezione. Se utilizzi urllib, urllib2 o httplib librerie per recuperare gli URL, la risposta viene sempre troncata e viene sollevata un'eccezione.

Utilizzo del recupero URL sul server di sviluppo

Quando l'applicazione è in esecuzione sul server di sviluppo di App Engine sul tuo computer, le chiamate al servizio di recupero URL vengono gestite localmente. La il server di sviluppo recupera gli URL contattando direttamente gli host remoti dal computer, utilizzando qualsiasi configurazione di rete per accedere a Internet.

Quando testi le funzionalità della tua applicazione che recuperano gli URL, assicurati che in modo che il tuo computer possa accedere agli host remoti.

Quote e limiti per il recupero degli URL

Per informazioni sulle quote del servizio di recupero URL, consulta Quote. Per visualizzare l'utilizzo attuale della quota l'applicazione, vai alla pagina Dettagli quota nella console Google Cloud.

Vai alla pagina Dettagli quota

Inoltre, i seguenti limiti si applicano all'uso dei Servizio di recupero URL:

Limite	Importo
Richiedi dimensioni	10 MB
Dimensioni intestazione della richiesta	16 kB (tieni presente che questo limita la lunghezza massima del URL che può essere specificato nell'intestazione)
Dimensioni risposta	32 megabyte

Passaggi successivi

Esegui esempi di codice e ottieni indicazioni su come inviare richieste dal tuo nell'emissione di richieste HTTP(S).