Esta página foi traduzida pela API Cloud Translation.

Suporte para cabeçalhos de resposta HTTP

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Neste tópico, descrevemos como o Edge processa cabeçalhos de cache HTTP/1.1 quando a política ResponseCache é usada. Atualmente, o Apigee Edge oferece suporte a um subconjunto de cabeçalhos e diretivas de armazenamento em cache HTTP/1.1 (recursos incompatíveis estão listados neste tópico) recebidos de servidores de back-end de destino (origem).

Além disso, com determinados cabeçalhos, o Edge realiza ações com base nas diretivas deles. Em alguns casos, esses cabeçalhos de cache HTTP/1.1 substituem qualquer comportamento especificado na política ResponseCache. Por exemplo, se o cabeçalho Cache-Control for retornado de um servidor de back-end, será possível usar a diretiva s-maxage do cabeçalho para possivelmente substituir outras configurações de expiração na política.

Observação:como usar cabeçalhos para influenciar chaves de cache e TTL de entrada de cache é possível fazer com que o Edge use cabeçalhos de resposta ao criar chaves de cache de resposta e definir TTL de entrada de cache. Para fazer isso, use estes elementos de sinalização da política ResponseCache:

<UseResponseCacheHeaders>: quando definido como true, o Edge vai considerar os cabeçalhos de resposta HTTP usados ao definir o "time to live" (TTL) da resposta no cache. Para mais detalhes, consulte "Como configurar a expiração da entrada de cache" e <UseResponseCacheHeaders> na política de cache de resposta.
<UseAcceptHeader>: quando definido como true, o Edge usará cabeçalhos Accept de resposta para aumentar a chave de cache. Para mais informações, consulte <UseAcceptHeader> na política de cache de resposta.

Header	Suporte
Cache-Control	Compatível com respostas retornadas de servidores de origem de back-end, mas não com solicitações de clientes. O Edge oferece suporte a um subconjunto de diretivas.
Expira em	Compatível. Pode ser substituída.
Tags de entidade (ETags)	Comportamento específico para If-Match e If-None-Match.
If-Modified-Since	Nas solicitações GET, o cabeçalho é transmitido para o servidor de origem, mesmo que exista uma entrada de cache válida.
Accept-Encoding	O Edge envia respostas compactadas ou não compactadas, dependendo dos cabeçalhos de entrada.

Cache-Control

O Apigee Edge só oferece suporte ao cabeçalho Cache-Control em respostas retornadas dos servidores de origem de back-end. A especificação HTTP/1.1 permite cabeçalhos Cache-Control nas solicitações do cliente e nas respostas do servidor de origem. Os servidores de origem podem incluir os endpoints de destino definidos em um proxy da API Apigee Edge e aqueles criados usando chamadas da API TargetServer.

Limitações de compatibilidade do Cache-Control

O Apigee Edge oferece suporte a um subconjunto de recursos de cabeçalho de resposta Cache-Control definidos na especificação HTTP/1.1. Observações:

O Apigee Edge não é compatível com cabeçalhos Cache-Control que chegam com solicitações de entrada de clientes.
O Apigee Edge só permite o uso de caches públicos. De acordo com a especificação HTTP, Cache-Control pode ser público (compartilhado) ou particular (usuário único).
O Apigee Edge é compatível apenas com um subconjunto de diretivas de resposta Cache-Control na especificação HTTP/1.1. Consulte Compatibilidade com diretivas de cabeçalho de resposta do Cache-Control para saber detalhes.

Compatibilidade com diretivas de cabeçalho de resposta do Cache-Control

A Apigee é compatível com uma diretiva de subconjunto da especificação HTTP/1.1 em respostas de servidores de origem. Na tabela a seguir, descrevemos o suporte do Apigee Edge para as diretivas de cabeçalho de resposta de controle de cache HTTP.

Para informações mais detalhadas sobre as diretivas listadas aqui, consulte Cache-Control na especificação HTTP/1.1.

Diretiva Cache-Control	Como o Apigee Edge processa a diretiva
`cache-extension`	Incompatível.
`max-age`	Se sua política ResponseCache definir o elemento `<UseResponseCacheHeaders>` como `true`, a resposta poderá ser armazenada em cache pelo número de segundos especificado por esta diretiva. Essa diretiva é modificada pela diretiva `s-maxage` e substitui o cabeçalho `Expires`. Ela também pode ser modificada pelo elemento `<ExpirySettings>` da política. Para mais informações, consulte "Como configurar a expiração da entrada de cache" e `<UseResponseCacheHeaders>` na política de cache de resposta. Observação: o conteúdo armazenado em cache com a política ResponseCache manterá o valor de max-age definido pela origem. Isso significa que, quando recuperado do cache, o conteúdo pode ser mais antigo do que o valor de max-age sugere (mais antigo que o cliente sabe).
`must-revalidate`	Incompatível. Todas as entradas de cache são excluídas pelo Apigee Edge assim que expiram.
`no-cache`	A borda armazena a resposta de origem em cache, mas ela precisa ser revalidada com o servidor de origem antes de ser usada para atender a solicitações subsequentes do cliente. Essa regra permite que a origem retorne uma resposta 304 Not Modified, indicando que a resposta precisa ser retornada do cache, economizando o processamento necessário para retornar toda a resposta. Se o servidor de origem retornar uma resposta completa, ele substituirá a entrada de cache atual. Nomes de campo especificados com essa diretiva são ignorados. Observação:o cabeçalho HTTP/1.0 `Pragma: no-cache` é tratado como equivalente a `Cache-Control: no-cache`.
`no-store`	Incompatível.
`no-transform`	Incompatível.
`private`	Incompatível. Se essa diretiva for recebida, a resposta de origem não será armazenada em cache. Todos os nomes de campo são ignorados.
`proxy-revalidate`	Incompatível. Todas as entradas de cache são excluídas pelo Apigee Edge assim que expiram.
`public`	A borda armazena em cache a resposta de origem, mesmo quando outras diretivas indicam o contrário. De acordo com a especificação HTTP/1.1, a única exceção a essa regra é se a resposta incluir um cabeçalho de autorização.
`s-maxage`	Se sua política ResponseCache definir o elemento `<UseResponseCacheHeaders>` como `true`, a resposta poderá ser armazenada em cache pelo número de segundos especificado por esta diretiva. Esta diretiva substitui a diretiva `max-age` e o cabeçalho `Expires`. Ela pode ser modificada pelo elemento `<ExpirySettings>` da política. Para mais informações, consulte "Como configurar a expiração da entrada de cache" e `<UseResponseCacheHeaders>` na política de cache de resposta. Observação: o conteúdo armazenado em cache com a política ResponseCache manterá o valor s-maxage definido pela origem. Isso significa que, quando recuperado do cache, o conteúdo pode ser mais antigo do que o valor s-maxage sugere (mais antigo que o cliente sabe).

Vence em

Quando a sinalização UseResponseCacheHeaders na política ResponseCache estiver definida como true, o Edge poderá usar o cabeçalho Expires para determinar o time to live (TTL) de uma entrada armazenada em cache. Esse cabeçalho especifica uma data/hora. Depois dela, a entrada de cache da resposta é considerada desatualizada. Esse cabeçalho permite que os servidores sinalizem quando é possível retornar um valor armazenado em cache com base em um carimbo de data/hora.

Observação: as diretivas max-age e s-maxage de cabeçalho Cache-Control têm precedência e substituem o cabeçalho Expires. Para mais informações, consulte "Como configurar a expiração da entrada de cache" e <UseResponseCacheHeaders> na política de cache de resposta.

Os formatos de data aceitáveis para o cabeçalho Expires estão descritos na especificação HTTP/1.1. Exemplo:

Expira em: quinta-feira, 01 de dezembro de 1994 16:00:00 GMT

Para informações detalhadas sobre formatos de data/hora HTTP, consulte Formatos de data/hora na especificação HTTP/1.1.

Observação:embora a seção 14.21 da especificação indique que um valor Expires de mais de um ano no futuro significa que uma entrada de cache nunca expira, a Apigee interpreta esse valor como significando que a entrada precisa ser armazenada em cache até a data e hora especificadas.

Para mais informações sobre o cabeçalho Expires, consulte Definições de campos de cabeçalho na especificação HTTP/1.1.

ETag

Uma tag de entidade (ETag) é um identificador associado a um recurso solicitado. Ao usar uma ETag, um servidor pode determinar se o recurso solicitado e o recurso armazenado em cache correspondem. Por exemplo, o servidor poderá armazenar em cache novamente a resposta caso ela não corresponda à informação armazenada no momento. Ele pode retornar o recurso armazenado em cache caso as ETags sejam correspondentes.

Quando um endpoint de destino envia uma resposta de volta ao Edge com uma ETag, o Edge armazena a ETag junto com a resposta.

Leia mais sobre tags de entidade em Parâmetros de protocolo na especificação HTTP/1.1.

If-Match

Com o cabeçalho de solicitação If-Match, uma entidade armazenada em cache será atual caso a ETag no cabeçalho corresponda à ETag em cache. Todas as solicitações diferentes de GET que especificam um cabeçalho If-Match são transmitidas ao servidor de origem para garantir que qualquer recurso de armazenamento em cache de origem tenha a chance de processar a solicitação.

Leia mais sobre If-Match em Definições de campos de cabeçalho na especificação HTTP/1.1.

Se o Edge receber uma solicitação GET de entrada de um cliente que inclui um cabeçalho If-Match:

Se	Then
O cabeçalho `If-Match` especifica uma ou mais ETags	O Apigee Edge recupera as entradas de cache não expiradas para o recurso especificado e compara todas as ETags fortes nessas entradas em cache com aquelas especificadas no cabeçalho `If-Match`. Se uma correspondência for encontrada, a entrada do cache será retornada. Caso contrário, a solicitação será transmitida para o servidor de origem.
O cabeçalho `If-Match` especifica "*"	A solicitação é transmitida ao servidor de origem para garantir que qualquer recurso de armazenamento em cache de origem tenha a chance de processar a solicitação.
Uma entrada de cache com o mesmo URI de solicitação foi encontrada, mas contém apenas ETags fracas	A entrada precisa ser revalidada pelo servidor de origem antes de ser retornada ao cliente.
As ETags são provenientes do servidor de origem.	A ETag é retornada sem alteração ao cliente

If-None-Match

Com o cabeçalho If-None-Match, uma entidade armazenada em cache será atual caso a ETag no cabeçalho não corresponda à ETag em cache. Solicitações diferentes de um GET que contenham esse cabeçalho são transmitidas para o servidor de origem.

Se o Edge receber uma solicitação GET de entrada com este cabeçalho:

Se	Then
O cabeçalho `If-None-Match` especifica uma ou mais ETags	O Apigee Edge recupera todas as entradas de cache não expiradas para o URI especificado e compara todas as ETags fortes nessas entradas em cache com aquelas especificadas no cabeçalho `If-None-Match`. Se uma correspondência for encontrada, o Edge retornará um status 304 Not Modified. Se nenhuma correspondência for encontrada, o Edge transmitirá a solicitação para o servidor de origem.
O cabeçalho `If-None-Match` especifica "*" e uma entrada em cache não expirada para o URI solicitado	O Edge retorna um status 304 Not Modified
Uma entrada de cache com o mesmo URI de solicitação foi encontrada, mas contém apenas ETags fracas	A entrada precisa ser revalidada pelo servidor de origem antes que o Edge a retorne ao cliente
A borda recebe uma ETag de um servidor de origem	A ETag é retornada sem alteração ao cliente

If-Modified-Since

Se o Apigee Edge receber um cabeçalho If-Modified-Since em uma solicitação GET, ele será transmitido para o servidor de origem mesmo que exista uma entrada de cache válida.

Isso garante que todas as atualizações em um recurso que não tenha passado pelo Apigee Edge sejam contabilizadas. Se o servidor de origem retornar uma nova entidade, o Edge substituirá a entrada de cache atual pelo novo valor. Se o servidor retornar um status 304 Not Modified, o Edge retornará o valor da resposta se o cabeçalho Last-Modified da resposta armazenada em cache indicar que ela não foi alterada.

Accept-Encoding

Quando uma solicitação recebida inclui o cabeçalho Accept-Encoding com valores de gzip, deflate ou compress, o servidor de origem responde com dados compactados. Quando as solicitações subsequentes vêm sem os cabeçalhos Accept-Encoding, elas esperam uma resposta não compactada. O mecanismo de armazenamento em cache de respostas da Apigee é capaz de enviar respostas compactadas e não compactadas, dependendo dos cabeçalhos de entrada, sem ter que voltar ao servidor de origem.

A opção "Aceitar valores de cabeçalho" pode ser anexada a chaves de cache para tornar as chaves mais significativas para cada item em cache. Para mais detalhes, consulte "Como configurar uma chave de cache" na Política de cache de resposta.