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).

Pedidos

O App Engine usa o serviço de busca de URL para emitir solicitações de saída. A linguagem PHP oferece várias funções para fazer solicitações HTTP remotas. Elas são implementadas de diferentes maneiras no Google App Engine e estão sujeitas a várias cotas e custos: para mais informações sobre os diferentes tipos, consulte Como emitir solicitações HTTP(S).

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. O prazo máximo é de 60 segundos para solicitações HTTP(S), para fila de tarefas e solicitações de cron job.

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. Os dados de solicitação e resposta são transmitidos pela rede em formato criptografado.

Na API PHP, por padrão, o proxy de busca de URL valida o host que ele está acessando. Esse comportamento permite que a API detecte ataques intermediários entre o App Engine e o host remoto ao usar HTTPS.

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 ao aplicativo.

Se a resposta de entrada exceder o limite de tamanho máximo, o serviço de busca de URL a truncará automaticamente. Consulte a seção Cotas e limites para os detalhes.

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
Prazo máximo (gerenciador de solicitação) 60 segundos
Prazo máximo (Fila de tarefas e gerenciador de cron job) 60 segundos

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).