Cabeçalhos e respostas 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 dos 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.

Solicitações e WSGI

O servidor determina qual objeto de aplicativo Python chamar, comparando o URL da solicitação com os padrões de URL no arquivo de configuração do aplicativo. Em seguida, o objeto do aplicativo é chamado usando os argumentos, conforme definido no padrão WSGI. O objeto do aplicativo executa ações apropriadas à solicitação. Em seguida, prepara uma resposta e a retorna como uma lista de strings.

A maioria dos aplicativos usa uma biblioteca, como webapp2, para processar solicitações WSGI. webapp2 está incluído como parte do ambiente de execução do Python 2.7.

Solicitações e CGI

O servidor determina qual script de gerenciador do Python executar comparando o URL da solicitação com os padrões de URL no arquivo de configuração do app. Em seguida, ele executa o script em um ambiente preenchido com os dados da solicitação. Conforme descrito no padrão CGI, o servidor coloca os dados da solicitação em variáveis de ambiente e no streaming de entrada padrão. O script realiza ações apropriadas à solicitação, prepara uma resposta e a coloca no streaming de saída padrão.

A maioria dos aplicativos usa uma biblioteca para analisar solicitações CGI e retornar respostas CGI, como o módulo cgi da biblioteca padrão do Python, ou uma biblioteca da Web que conheça o protocolo CGI (como webapp). Você pode consultar a documentação de CGI para detalhes sobre as variáveis de ambiente e o formato dos dados de streaming de entrada.

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 ISO 3166-1 alfa-2 de país. 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 processar o código especial de 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 em Mountain View.
O Python é compatível com o mesmo conjunto de cabeçalhos HTTP de entrada conforme listado acima, incluindo os seguintes itens, entre outros:

  • 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 serviço Cron 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 disponibilizadas 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á posteriormente 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 de resposta, o servidor poderá compactar automaticamente o corpo de 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

Define a data e hora atuais.

Server

Define o Google Frontend. No servidor de desenvolvimento, ele é definido como Development/x, em que x é o número da versão.

Se você acessar páginas dinâmicas em seu site enquanto estiver conectado com uma conta de administrador, os cabeçalhos de resposta terão estatísticas por solicitação:

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 Python 2