Busca de URL para serviços agrupados legados

Nesta página, você saberá como os aplicativos do App Engine usam o serviço de busca de URL para emitir solicitações HTTP e HTTPS e receber respostas. Para ver exemplos de código que demonstram como emitir solicitações HTTP e HTTPS pelo aplicativo App Engine, consulte Como emitir solicitações HTTP(S).

Se você tiver configurado o acesso VPC sem servidor ou se usar a API Sockets, precisará interromper o processamento de solicitações da busca de URL. A busca de URL faz com que as solicitações para sua rede VPC ou para a API Sockets falhem. Depois de desativar a busca de URL, a biblioteca Python padrão processará solicitações HTTP. Se você precisar dos recursos fornecidos pela busca de URL para solicitações específicas, poderá usar a biblioteca urlfetch diretamente para essas solicitações específicas.

Essa API é compatível com os ambientes de execução de primeira geração e pode ser usada ao fazer upgrade para os ambientes de execução de segunda geração correspondentes. Se você estiver atualizando para o ambiente de execução do Python 3 do App Engine, consulte o guia de migração para saber mais sobre as opções de migração para serviços incluídos legados.

Pedidos

O App Engine usa o serviço de busca de URL para emitir solicitações de saída. No Python, é possível usar as bibliotecas httplib, urllib e urllib2 para fazer solicitações HTTP. Em um aplicativo do App Engine, cada biblioteca realizará essas solicitações usando o serviço de busca de URL. Você também pode usar a biblioteca urlfetch diretamente.

Protocolos de solicitação

Um aplicativo pode buscar um URL usando HTTP ou HTTPS. O protocolo que precisa ser usado é inferido observando-se o protocolo no URL de destino.

O URL buscado pode usar qualquer número de porta nestes intervalos:

• 80-90
• 440-450
• 1024-65535.

Se a porta não for mencionada no URL, ela estará implícita no protocolo. As solicitações HTTP ocorrem na porta 80 e as HTTPS ocorrem na porta 443.

Métodos de solicitação

Se você emitir solicitações por meio do serviço de busca de URL, poderá usar qualquer um dos seguintes métodos HTTP:

• GET
• POST
• PUT
• HEAD
• DELETE
• PATCH

Uma solicitação pode incluir cabeçalhos HTTP e, para solicitações POST, PUT e PATCH, um payload.

Proxy das solicitações

O serviço de busca de URL usa um proxy compatível com HTTP/1.1 para buscar o resultado.

Para evitar que um aplicativo cause uma recursão interminável de solicitações, não é permitido que um gerenciador de solicitações busque o próprio URL. Ainda é possível causar uma recursão interminável com outros meios, por isso tenha cuidado se o aplicativo puder ser usado para buscar solicitações de URLs fornecidas pelo usuário.

Cabeçalhos de solicitação

O aplicativo pode configurar cabeçalhos HTTP para a solicitação de saída.

Ao enviar uma solicitação HTTP POST, se um cabeçalho Content-Type não for definido explicitamente, ele será definido como x-www-form-urlencoded. Esse é o tipo de conteúdo usado pelos formulários da Web.

Por motivos de segurança, os cabeçalhos abaixo não podem ser modificados pelo aplicativo:

• Content-Length
• Host
• Vary
• Via
• X-Appengine-Inbound-Appid
• X-Forwarded-For
• X-ProxyUser-IP

Esses cabeçalhos são definidos com valores precisos pelo App Engine, conforme apropriado. Por exemplo, o Google App Engine calcula o cabeçalho Content-Length com base nos dados de solicitação e o adiciona à solicitação antes do envio.

Os seguintes cabeçalhos indicam o ID do app solicitante:

• User-Agent. Este cabeçalho pode ser modificado, mas o App Engine anexará uma string de identificação para permitir que os servidores identifiquem as solicitações do App Engine. A string anexada tem o formato "AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", em que APPID é o identificador do app.
• X-Appengine-Inbound-Appid. Esse cabeçalho não pode ser modificado e será adicionado automaticamente se a solicitação for enviada pelo serviço de busca de URL quando o parâmetro "follow redirects" for definido como False.

Tempo limite das solicitações

É possível definir um prazo ou tempo limite para uma solicitação. Por padrão, o tempo limite de uma solicitação é 10 segundos.

É possível enviar solicitações síncronas e assíncronas. O seguinte comportamento se aplica à API URL Fetch:

• Solicitações síncronas: a chamada de busca aguarda até que o host remoto retorne um resultado e, em seguida, retorna o controle para o aplicativo. Se o tempo de espera máximo para a chamada de busca for excedido, a chamada gerará uma exceção.
• Solicitações assíncronas: o serviço de busca de URL inicia a solicitação e retorna imediatamente um objeto. O aplicativo pode realizar outras tarefas durante a busca do URL. Quando o aplicativo precisa dos resultados, ele chama um método no objeto, que aguarda até que a solicitação seja concluída, se necessário, e depois retorna o resultado. Se alguma solicitação de busca de URL estiver pendente quando o gerenciador de solicitações é encerrado, o servidor de aplicativos espera até que o restante das solicitações retorne ou atinja o prazo antes de retornar uma resposta para o usuário.

Conexões seguras e HTTPS

Seu aplicativo pode buscar um URL de maneira segura por meio do uso do HTTPS para se conectar a servidores seguros. Dados de solicitação e resposta são transmitidos pela rede em formato criptografado.

Na API Python, o proxy de busca de URL não valida o host que está entrando em contato por padrão. Você pode adicionar um argumento validate_certificate opcional ao método fetch() para ativar a validação do host.

Observação: o módulo urllib não fornece métodos para validar hosts.

Respostas

Se você usar a API URL Fetch, o serviço de busca de URL retornará todos os dados de resposta, inclusive a resposta, o código, os cabeçalhos e o corpo.

Por padrão, se o serviço de busca de URL receber uma resposta com um código de redirecionamento, ele acompanhará esse redirecionamento. O serviço acompanhará até cinco respostas de redirecionamento e, em seguida, retornará o recurso final. É possível instruir o serviço de busca de URL para que não siga redirecionamentos e, em vez disso, retornar uma resposta de redirecionamento para o aplicativo.

Observação: a API URL Fetch impõe limites sobre o tamanho da resposta. Se a resposta de entrada exceder o limite de tamanho máximo de resposta, o serviço de busca de URL gerará uma exceção. Consulte a seção Cotas e limites para detalhes.

Você pode instruir a API URL Fetch para truncar a resposta em vez de gerar uma exceção. Se você usar as bibliotecas urllib, urllib2 ou httplib para buscar URLs, a resposta será sempre truncada e nenhuma exceção será gerada.

Como usar a busca de URL no servidor de desenvolvimento

Quando o aplicativo está em execução no servidor de desenvolvimento do App Engine no computador, as chamadas para o serviço de busca de URL são processadas localmente. O servidor de desenvolvimento busca URLs por meio do contato com hosts remotos diretamente do seu computador usando a configuração de rede do computador para acessar a Internet.

Ao testar os recursos do seu aplicativo que buscam URLs, verifique se o computador pode acessar os hosts remotos.

Cotas e limites para busca de URL

Para informações sobre cotas de serviço de busca de URL, consulte Cotas. Para ver o uso atual da cota do aplicativo, acesse a página "Detalhes da cota" no console do Google Cloud.

Acessar a página "Detalhes da cota"

Além disso, os seguintes limites aplicam-se ao uso do serviço de busca de URL:

Limite	Valor
Tamanho da solicitação	10 megabytes
Tamanho do cabeçalho da solicitação	16 KB (observe que isso limita o comprimento máximo do URL que pode ser especificado no cabeçalho)
Tamanho da resposta	32 megabytes

Próximas etapas

Execute exemplos de código e veja as instruções sobre como emitir solicitações pelo aplicativo em Como emitir solicitações HTTP(S).