URL Fetch para serviços agrupados antigos

Esta página descreve como as aplicações do App Engine usam o serviço URL Fetch para emitir pedidos HTTP e HTTPS e receber respostas. Para ver exemplos de código que demonstram como emitir pedidos HTTP e HTTPS a partir da sua aplicação do App Engine, consulte o artigo Emitir pedidos HTTP(S).

Pedidos

O App Engine usa o serviço URL Fetch para emitir pedidos de saída. A linguagem PHP oferece várias funções para fazer pedidos HTTP remotos. Estas são implementadas de diferentes formas no App Engine e estão sujeitas a custos e quotas diferentes. Para mais informações sobre os diferentes tipos, consulte o artigo Emitir pedidos HTTP(S).

Protocolos de pedidos

Uma aplicação pode obter um URL através de HTTP ou HTTPS. O protocolo que deve ser usado é inferido através da análise do protocolo no URL de destino.

O URL a obter pode usar qualquer número de porta nos seguintes intervalos:

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

Se a porta não for mencionada no URL, a porta é implícita no protocolo. Os pedidos HTTP ocorrem na porta 80 e os pedidos HTTPS ocorrem na porta 443.

Métodos de pedido

Se emitir pedidos através do serviço URL Fetch, pode usar qualquer um dos seguintes métodos HTTP:

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

Um pedido pode incluir cabeçalhos HTTP e, para pedidos POST, PUT e PATCH, um payload.

Encaminhamento por proxy de pedidos

Tenha em atenção que o serviço URL Fetch usa um proxy compatível com HTTP/1.1 para obter o resultado.

Para impedir que uma aplicação cause uma recursão infinita de pedidos, um controlador de pedidos não pode obter o seu próprio URL. Ainda é possível causar uma recursão infinita por outros meios. Por isso, tenha cuidado se a sua aplicação puder ser feita para obter pedidos de URLs fornecidos pelo utilizador.

Cabeçalhos do pedido

A sua aplicação pode definir cabeçalhos HTTP para o pedido de saída.

Quando envia um pedido HTTP POST, se um cabeçalho Content-Type não for definido explicitamente, o cabeçalho é definido como x-www-form-urlencoded. Este é o tipo de conteúdo usado pelos formulários Web.

Por motivos de segurança, não é possível modificar os seguintes cabeçalhos pela aplicação:

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

Estes cabeçalhos são definidos com valores precisos pelo App Engine, conforme adequado. Por exemplo, o App Engine calcula o cabeçalho Content-Length a partir dos dados do pedido e adiciona-o ao pedido antes de o enviar.

Os seguintes cabeçalhos indicam o ID da aplicação da app requerente:

  • User-Agent. Este cabeçalho pode ser modificado, mas o App Engine anexa uma string de identificador para permitir que os servidores identifiquem os pedidos do App Engine. A string anexada tem o formato "AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", em que APPID é o identificador da sua app.
  • X-Appengine-Inbound-Appid. Este cabeçalho não pode ser modificado e é adicionado automaticamente se o pedido for enviado através do serviço URL Fetch quando o parâmetro follow redirects estiver definido como False.

Limites de tempo dos pedidos

Pode definir um prazo ou um tempo limite para um pedido. Por predefinição, o tempo limite de um pedido é de 10 segundos. O prazo máximo é de 60 segundos para pedidos HTTP(S) e 60 segundos para pedidos de tarefas agendadas e filas de tarefas.

Ligações seguras e HTTPS

A sua aplicação pode obter um URL de forma segura através do HTTPS para estabelecer ligação a servidores seguros. Os dados de pedido e resposta são transmitidos através da rede de forma encriptada.

Por predefinição, o proxy URL Fetch valida o anfitrião com o qual contacta. Este comportamento permite à API detetar ataques man-in-the-middle entre o App Engine e o anfitrião remoto quando usa HTTPS.

Responses

Se usar a API URL Fetch, tenha em atenção que o serviço URL Fetch devolve todos os dados de resposta, incluindo a resposta, o código, os cabeçalhos e o corpo.

Por predefinição, se o serviço URL Fetch receber uma resposta com um código de redirecionamento, o serviço segue o redirecionamento. O serviço segue até cinco respostas de redirecionamento e, em seguida, devolve o recurso final. Pode dar instruções ao serviço URL Fetch para não seguir redirecionamentos e, em alternativa, devolver uma resposta de redirecionamento à aplicação.

Se a resposta recebida exceder o limite de tamanho máximo da resposta, o serviço de obtenção de URL trunca automaticamente a resposta. Consulte a secção Quotas e limites para ver detalhes.

Usar a obtenção de URLs no servidor de desenvolvimento

Quando a sua aplicação está em execução no servidor de desenvolvimento do App Engine no seu computador, as chamadas ao serviço URL Fetch são processadas localmente. O servidor de desenvolvimento obtém URLs contactando diretamente anfitriões remotos a partir do seu computador, usando qualquer configuração de rede que o computador esteja a usar para aceder à Internet.

Quando testar as funcionalidades da sua aplicação que obtêm URLs, certifique-se de que o seu computador consegue aceder aos anfitriões remotos.

Quotas e limites para a obtenção de URLs

Para ver informações sobre as quotas do serviço de obtenção de URL, consulte o artigo Quotas. Para ver a utilização atual da quota da sua aplicação, aceda à página Detalhes da quota naGoogle Cloud consola.

Aceda à página Detalhes da quota

Além disso, aplicam-se os seguintes limites à utilização do serviço URL Fetch:

Limite Montante
Tamanho do pedido 10 megabytes
Tamanho do cabeçalho do pedido 16 KB (tenha em atenção que isto limita o comprimento máximo do URL que pode ser especificado no cabeçalho)
Tamanho da resposta 32 megabytes
Prazo máximo (processador de pedidos) 60 segundos
Prazo máximo (fila de tarefas e controlador de tarefas cron) 60 segundos

O que se segue?

Execute exemplos de código e receba orientações sobre como emitir pedidos a partir da sua aplicação em Emitir pedidos HTTP(S).