Respostas e cabeçalhos de solicitação

Use esta página de referência para ver mais detalhes sobre quais cabeçalhos HTTP são compatíveis, além de limites de solicitação e resposta no App Engine. Para entender como funciona o recebimento de solicitações e o envio de respostas no App Engine, consulte Como as solicitações são processadas.

Cabeçalhos de solicitação

Uma solicitação HTTP recebida inclui os cabeçalhos HTTP enviados pelo cliente. Para fins de segurança, alguns cabeçalhos são limpos ou retificados por proxies intermediários antes de chegarem ao aplicativo.

Cabeçalhos removidos

Os seguintes cabeçalhos são removidos da solicitação:

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

Além disso, o cabeçalho Strict-Transport-Security é removido das solicitações veiculadas para outros domínios, exceto appspot.com ou *.appspot.com.

Esses cabeçalhos referem-se à transferência dos dados HTTP entre o cliente e o servidor e são transparentes para o aplicativo. Por exemplo, o servidor pode enviar automaticamente uma resposta compactada em gzip, dependendo do valor do cabeçalho da solicitação Accept- Encoding. O aplicativo em si não precisa saber quais codificações de conteúdo o cliente pode aceitar.

Cabeçalhos específicos do App Engine

Como um serviço ao aplicativo, o App Engine adiciona estes cabeçalhos a todas as solicitações:

X-AppEngine-Country
País de origem da solicitação, como um código de país ISO 3166-1 alfa-2. O App Engine determina esse código a partir do endereço IP do cliente. As informações do país não são derivadas do banco de dados WHOIS. É possível que um endereço IP com informações do país no banco de dados WHOIS não tenha essas informações no cabeçalho X-AppEngine-Country. O aplicativo precisa lidar com o código especial do país ZZ (país desconhecido).
X-AppEngine-Region
Nome da região de origem da solicitação. Esse valor faz sentido apenas no contexto do país em X -AppEngine-Country. Por exemplo, se o país for "US" e a região for "ca", esse "ca" significará "Califórnia", e não Canadá. Você pode encontrar a lista completa de valores regionais válidos no padrão ISO-3166-2.
X-AppEngine-City
Nome da cidade de origem da solicitação. Por exemplo, uma solicitação da cidade de Mountain View pode ter o valor de cabeçalho mountain view. Não há uma lista canônica de valores válidos para esse cabeçalho.
X-AppEngine-CityLatLong
Latitude e longitude da cidade de origem da solicitação. Essa string pode ser "37.386051, -122.083851" para uma solicitação de Mountain View.
O Java é compatível com o mesmo conjunto de cabeçalhos HTTP de entrada listado acima, incluindo, entre outros, os seguintes itens:

  • X-AppEngine-Https, com cabeçalho de exemplo: “off”
  • X-AppEngine-User-IP, com cabeçalho de exemplo: "2602:306:3429:520:501f:4a71:9d2c:be5f"
  • X-Cloud-Trace-Context, com cabeçalho de exemplo: "18ff88cd7f38ff2bf9b79443..."

Para os gerenciadores login:admin ou login:required especificados no app.yaml, o App Engine também fornece o seguinte conjunto de cabeçalhos:

  • X-AppEngine-User-Email, com cabeçalho de exemplo: "ange@example.com"
  • X-AppEngine-Auth-Domain, com cabeçalho de exemplo: "example.com"
  • X-AppEngine-User-ID, com cabeçalho de exemplo: "100979712376541954724"
  • X-AppEngine-User-Nickname, com cabeçalho de exemplo: "ange"
  • X-AppEngine-User-Organization, com cabeçalho de exemplo: "example.com"
  • X-AppEngine-User-Is-Admin, com cabeçalho de exemplo: "1"

Os serviços do App Engine podem adicionar outros cabeçalhos de solicitação:

  • Solicitações do Cron Service também contêm um cabeçalho HTTP:

    X-AppEngine-Cron: true

    Veja mais detalhes em Como proteger URLs para Cron.

  • As solicitações provenientes de outros aplicativos do App Engine incluem um cabeçalho que identifica o aplicativo que faz a solicitação:

    X-Appengine-Inbound-Appid

    Consulte a Documentação da App Identity para ver mais detalhes.

Respostas a solicitações

Esta documentação de cabeçalho HTTP aplica-se apenas a respostas a solicitações HTTP de entrada. A resposta pode ser modificada antes de ser retornada ao cliente. Para cabeçalhos HTTP relacionados a solicitações de saída originadas do seu código do App Engine, consulte a documentação de cabeçalho para URLFetch.

Cabeçalhos removidos

Os seguintes cabeçalhos são ignorados e removidos da resposta:

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

* Pode ser adicionado novamente se a resposta for compactada pelo App Engine.

Além disso, o cabeçalho Strict-Transport-Security é removido das respostas veiculadas por qualquer domínio que não seja *.appspot.com.

Os cabeçalhos com caracteres que não sejam ASCII no nome ou no valor também são removidos.

Cabeçalhos adicionados ou substituídos

Os seguintes cabeçalhos são adicionados ou substituídos na resposta:

Cache-Control, Expires e Vary

Esses cabeçalhos especificam a política de armazenamento em cache para proxies Web intermediários (como os provedores de acesso à Internet) e navegadores. Caso seu script defina esses cabeçalhos, eles geralmente não serão modificados, a menos que a resposta tenha um cabeçalho do Set-Cookie ou seja gerada para o usuário que efetuou o login usando uma conta de administrador. Os gerenciadores estáticos definirão esses cabeçalhos de acordo com as instruções do arquivo de configuração. Se você não especificar um Cache-Control, o servidor pode configurá-lo como private e adicionar um cabeçalho Vary: Accept-Encoding.

Se você tiver um cabeçalho de resposta Set-Cookie, o cabeçalho Cache-Control será configurado como private (se já não for mais restritivo) e o cabeçalho Expires será definido para a data atual (se não estiver no passado). Dessa forma, os navegadores geralmente podem armazenar a resposta em cache, mas não em servidores proxy intermediários. Isso ocorre por questões de segurança, porque se a resposta for armazenada em cache publicamente, outro usuário poderá depois solicitar o mesmo recurso e recuperar o cookie do primeiro usuário.

Content-Encoding

Dependendo dos cabeçalhos de solicitação e do Content-Type da resposta, o servidor poderá compactar automaticamente o corpo da resposta, como descrito anteriormente. Nesse caso, ele adiciona um cabeçalho Content-Encoding: gzip para indicar que o corpo está compactado. Consulte a seção sobre compactação de resposta para ver mais detalhes.

Content-Length ou Transfer-Encoding

O servidor sempre ignora o cabeçalho Content-Length retornado pelo aplicativo. Ele configura Content-Length com o comprimento do corpo (após a compactação, caso seja aplicada) ou exclui Content-Length e usa a codificação de transferência fragmentada (adicionando um cabeçalho Transfer-Encoding: chunked).

Content-Type

Se não for especificado pelo aplicativo, o servidor definirá um cabeçalho Content-Type: text/html padrão.

Date

Definida como a data e hora atuais.

Server

Define o Google Frontend.

Se você acessar páginas dinâmicas no seu site enquanto estiver conectado usando uma conta de administrador, o App Engine incluirá estatísticas por solicitação nos cabeçalhos de resposta.

X-AppEngine-Estimated-CPM-US-Dollars
Uma estimativa de quanto custam 1.000 solicitações semelhantes a esta em dólares americanos.
X-AppEngine-Resource-Usage
Os recursos utilizados pela solicitação, incluindo o tempo do servidor em milissegundos.

As respostas com estatísticas de uso de recursos não poderão ser armazenadas em cache.

Se o cabeçalho X-AppEngine-BlobKey estiver na resposta do aplicativo, ele e o cabeçalho opcional X-AppEngine-BlobRange serão usados para substituir o corpo por todo o conteúdo do blobstore blob ou parte dele. Se Content-Type não for especificado pelo aplicativo, ele será configurado para o tipo MIME do blob. Se houver solicitação de intervalo, o status da resposta será alterado para 206 Partial Content e um cabeçalho Content-Range será adicionado. Os cabeçalhos X-AppEngine-BlobKey e X -AppEngine-BlobRange serão removidos da resposta. Geralmente você não precisa definir esses cabeçalhos, porque a classe blobstore_handlers.BlobstoreDownloadHandler faz isso. Consulte Como veicular um blob para ver detalhes.

Cabeçalhos de resposta configurados no aplicativo

Os cabeçalhos de resposta HTTP personalizados podem ser configurados por URL para caminhos dinâmicos e estáticos no arquivo de configuração do aplicativo. Consulte as seções http_headers na documentação de configuração para ver mais detalhes.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Ambiente padrão do App Engine para Java 8