Cabeçalhos dos pedidos e respostas

Go Java Node.js PHP Python Ruby

ID da região

O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após fevereiro de 2020, REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criadas antes desta data, o ID da região é opcional no URL.

Saiba mais acerca dos IDs de regiões.

OK

Use esta página de referência para ver detalhes sobre os cabeçalhos HTTP suportados, bem como os limites de pedidos e respostas no App Engine. Para compreender como o App Engine recebe pedidos e envia respostas, consulte o artigo Como os pedidos são processados.

Cabeçalhos do pedido

Um pedido HTTP de entrada inclui os cabeçalhos HTTP enviados pelo cliente. Por motivos de segurança, alguns cabeçalhos são limpos, alterados ou removidos por proxies intermédios antes de chegarem à aplicação.

Cabeçalhos removidos de pedidos recebidos

Os seguintes cabeçalhos são removidos dos pedidos recebidos se um cliente os enviar:

• Cabeçalhos com nomes que correspondem ao padrão X-Google-*. Este padrão de nome está reservado para a Google.

• Cabeçalhos com nomes que correspondem aos cabeçalhos específicos do App Engine. Apenas as correspondências exatas não sensíveis a maiúsculas e minúsculas são removidas. Por exemplo, os cabeçalhos com os nomes X-Appengine-Country ou X-AppEngine-Country são removidos, mas o cabeçalho com o nome X-Appengine-Cntry não é removido.

Além disso, os seguintes cabeçalhos são removidos dos pedidos recebidos porque se relacionam com a transferência dos dados HTTP entre o cliente e o servidor:

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

Por exemplo, o servidor pode enviar automaticamente uma resposta comprimida com gzip consoante o valor do cabeçalho do pedido Accept-Encoding. A própria aplicação não precisa de saber que codificações de conteúdo o cliente pode aceitar.

Nota: os cabeçalhos de entidades (cabeçalhos relacionados com o corpo do pedido) não são limpos nem verificados, pelo que as aplicações não devem depender deles. Em particular, o cabeçalho do pedido Content- MD5 é enviado sem modificações para a aplicação, pelo que pode não corresponder ao hash MD5 do conteúdo. Além disso, o cabeçalho do pedido Content-Encoding não é verificado pelo servidor. Por isso, se o cliente enviar um corpo do pedido comprimido com gzip, este é enviado de forma comprimida para a aplicação.

Cabeçalhos específicos do App Engine

Como um serviço para a app, o App Engine adiciona os seguintes cabeçalhos a todos os pedidos:

X-Appengine-Country

País de origem do pedido, como um código do país ISO 3166-1 alfa-2. O App Engine determina este código a partir do endereço IP do cliente. Tenha em atenção que as informações do país não são derivadas da base de dados WHOIS. É possível que um endereço IP com informações do país na base de dados WHOIS não tenha informações do país no cabeçalho X-Appengine-Country. A sua aplicação deve processar o código de país especial ZZ (país desconhecido).

X-Appengine-Region

Nome da região de origem do pedido. Este valor só faz sentido 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" significa "Califórnia" e não Canadá. A lista completa de valores de regiões válidos encontra-se na norma ISO-3166-2.

X-Appengine-City

Nome da cidade de origem do pedido. Por exemplo, um pedido da cidade de Mountain View pode ter o valor do cabeçalho mountain view. Não existe uma lista canónica de valores válidos para este cabeçalho. Se não for possível resolver a cidade, o valor do cabeçalho é definido como ?.

X-Appengine-CityLatLong

Latitude e longitude da cidade de origem do pedido. Esta string pode ter o seguinte aspeto: "37.386051,-122.083851" para um pedido de Mountain View. Se não for possível resolver a cidade, o valor do cabeçalho é definido como 0.000000,0.000000.

X-Cloud-Trace-Context

Um identificador exclusivo do pedido usado para o Cloud Trace e o Cloud Logging. Não existe uma opção para desativar este cabeçalho nem escolher a taxa de amostragem para a monitorização, uma vez que todas as apps do ambiente padrão do App Engine são monitorizadas automaticamente.

X-Forwarded-For: [CLIENT_IP(s)], [global forwarding rule IP]

Uma lista de endereços IP delimitada por vírgulas através dos quais o pedido do cliente foi encaminhado. Geralmente, o primeiro IP nesta lista é o IP do cliente que criou o pedido. Os IPs subsequentes fornecem informações sobre os servidores proxy que também processaram o pedido antes de chegar ao servidor de aplicações. Por exemplo:

X-Forwarded-For: clientIp, proxy1Ip, proxy2Ip

X-Forwarded-Proto [http | https]

Mostra http ou https com base no protocolo que o cliente usou para estabelecer ligação à sua aplicação.

O balanceador de carga do Google Cloud termina todas as ligações https e, em seguida, encaminha o tráfego para as instâncias do App Engine através de http. Por exemplo, se um utilizador pedir acesso ao seu site através de https://PROJECT_ID.REGION_ID.r.appspot.com, o valor do cabeçalho X-Forwarded-Proto é https.

Além disso, o App Engine pode definir os seguintes cabeçalhos que são para utilização interna pelo App Engine:

• X-Appengine-Https
• X-Appengine-User-IP
• X-Appengine-Api-Ticket
• X-Appengine-Request-Log-Id
• X-Appengine-Default-Version-Hostname
• X-Appengine-Timeout-Ms

Os serviços do App Engine podem adicionar cabeçalhos de pedidos adicionais:

• Os pedidos do serviço Cron adicionam o seguinte cabeçalho:

  X-Appengine-Cron: true

  Consulte o artigo Proteger URLs para o cron para ver mais detalhes.

Solicite respostas

Esta documentação de cabeçalhos HTTP aplica-se apenas a respostas a pedidos HTTP recebidos. A resposta pode ser modificada antes de ser devolvida ao cliente.

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 comprimida pelo App Engine.

Os cabeçalhos com carateres não 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

Estes cabeçalhos especificam a política de colocação em cache para proxies Web intermédios (como o frontend da Google e os fornecedores de serviços de Internet) e navegadores. Se a sua app definir estes cabeçalhos de resposta, normalmente, não são modificados, a menos que a sua app também defina um cabeçalho Set-Cookie ou a resposta seja gerada para um utilizador que tenha sessão iniciada com uma conta de administrador.

Se a sua app definir um cabeçalho de resposta Set-Cookie, o cabeçalho Cache-Control é definido como private (se ainda não for mais restritivo) e o cabeçalho Expires é definido como a data atual (se ainda não estiver no passado). Geralmente, isto permite que os navegadores armazenem em cache a resposta, mas não os servidores proxy intermédios. Isto deve-se a motivos de segurança, uma vez que, se a resposta fosse armazenada em cache publicamente, outro utilizador poderia solicitar posteriormente o mesmo recurso e obter o cookie do primeiro utilizador.

Nota: para todos os tempos de execução, exceto o Java, o servidor de desenvolvimento desativa a colocação em cache por predefinição (para o script e o conteúdo estático). Por isso, se não especificar cabeçalhos de colocação em cache, não terá conteúdo em cache enquanto desenvolve a sua app.

Se a sua app não definir o cabeçalho de resposta Cache-Control, o servidor pode defini-lo como private e adicionar um cabeçalho Vary: Accept-Encoding.

Para mais informações sobre o armazenamento em cache, incluindo a lista de valores Vary suportados pelo frontend da Google, consulte o artigo Armazenamento em cache de respostas.

Content-Encoding

Consoante os cabeçalhos dos pedidos e a resposta Content-Type, o servidor pode comprimir automaticamente o corpo da resposta, conforme descrito acima. Neste caso, adiciona um cabeçalho Content-Encoding: gzip para indicar que o corpo está comprimido. Consulte a secção sobre a compressão de respostas para mais detalhes.

Content-Length ou Transfer-Encoding

O servidor ignora sempre o cabeçalho Content-Length devolvido pela aplicação. Vai definir Content-Length para o comprimento do corpo (após a compressão, se esta for aplicada) ou eliminar Content-Length e usar a codificação de transferência segmentada (adicionando um cabeçalho Transfer-Encoding: chunked). Se Content-Length estiver definido incorretamente para runtimes de segunda geração, o App Engine devolve uma resposta 500.

Date

Definido para a data e hora atuais.

Server

Definido como Google Frontend. O servidor de desenvolvimento define este valor como Development/x, em que x é o número da versão.

Se aceder a páginas dinâmicas no seu site enquanto tem sessão iniciada com uma conta de administrador, o App Engine inclui estatísticas por pedido nos cabeçalhos de resposta:

X-Appengine-Resource-Usage

Os recursos usados pelo pedido, incluindo o tempo do lado do servidor como um número de milissegundos.

As respostas com estatísticas de utilização de recursos vão deixar de ser armazenáveis em cache.

Cabeçalhos de resposta definidos na configuração da aplicação

Os cabeçalhos de resposta HTTP personalizados podem ser definidos por URL para caminhos dinâmicos e estáticos no ficheiro de configuração da sua aplicação. Consulte as secções http_headers na documentação de configuração para mais detalhes.