Esta página foi traduzida pela API Cloud Translation.

Suporte para cabeçalhos de resposta HTTP

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Este tópico descreve como o Apigee processa os cabeçalhos de colocação em cache HTTP/1.1 quando usa a política ResponseCache. Atualmente, o Apigee suporta um subconjunto dos cabeçalhos de colocação em cache HTTP/1.1 e das diretivas (as funcionalidades não suportadas estão listadas neste tópico) recebidas dos servidores de destino (origem) de back-end.

Além disso, com determinados cabeçalhos, o Apigee toma medidas com base nas respetivas diretivas. Em alguns casos, estes cabeçalhos de cache HTTP/1.1 substituem qualquer comportamento especificado na política ResponseCache. Por exemplo, se o cabeçalho Cache-Control for devolvido por um servidor de back-end, pode fazer com que a diretiva s-maxage do cabeçalho substitua potencialmente outras definições de expiração na política.

Nota: usar cabeçalhos para influenciar as chaves de cache e o TTL da entrada de cache. Pode fazer com que o Apigee use cabeçalhos de resposta ao construir chaves de cache de resposta e definir o TTL da entrada de cache. Para o fazer, use estes elementos de flags da política ResponseCache:

<UseResponseCacheHeaders> -- Quando esta opção está definida como true, o Apigee considera os cabeçalhos de resposta HTTP usados quando define o "tempo de vida" (TTL) da resposta na cache. Para ver detalhes, consulte "Definir a expiração da entrada da cache" e <UseResponseCacheHeaders> em Política de cache de respostas.
<UseAcceptHeader> -- Quando esta opção está definida como true, o Apigee usa os cabeçalhos Accept de resposta para aumentar a chave da cache. Para mais informações, consulte a secção <UseAcceptHeader> na Política de Cache de Respostas.

Cabeçalho	Apoio técnico
Cache-Control	Suportado em respostas devolvidas por servidores de origem de back-end, mas não em pedidos de clientes. O Apigee suporta um subconjunto de diretivas.
Expira	Compatível. Pode ser substituído.
Etiquetas de entidade (ETags)	Comportamento específico para If-Match e If-None-Match.
If-Modified-Since	Em pedidos GET, o cabeçalho é transmitido ao servidor de origem, mesmo que exista uma entrada de cache válida.
Accept-Encoding	O Apigee envia respostas comprimidas ou não comprimidas, consoante os cabeçalhos recebidos.

Cache-Control

O Apigee suporta o cabeçalho Cache-Control apenas em respostas devolvidas de servidores de origem de back-end (a especificação HTTP/1.1 permite cabeçalhos Cache-Control em pedidos de clientes e respostas de servidores de origem). Os servidores de origem podem incluir pontos finais de destino definidos num proxy de API do Apigee e os criados através de chamadas da API TargetServer.

Limitações de suporte do Cache-Control

O Apigee suporta um subconjunto de capacidades do cabeçalho de resposta Cache-Control definidas na especificação HTTP/1.1. Tenha o seguinte em consideração:

O Apigee não suporta cabeçalhos Cache-Control que chegam com pedidos de clientes de entrada.
O Apigee só suporta a noção de caches públicas. (According to the HTTP specification, Cache-Control can either be public (shared) or private (single user).)
O Apigee suporta apenas um subconjunto de diretivas de resposta Cache-Control na especificação HTTP/1.1. Consulte o artigo Suporte para diretivas de cabeçalho de resposta Cache-Control para ver detalhes.

Suporte para diretivas do cabeçalho de resposta Cache-Control

O Apigee suporta um subconjunto de diretivas da especificação HTTP/1.1 em respostas de servidores de origem. A tabela seguinte descreve o suporte do Apigee para diretivas do cabeçalho de resposta HTTP Cache-Control.

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

Diretiva Cache-Control	Como o Apigee processa a diretiva
`cache-extension`	Não suportado.
`max-age`	Se a sua política ResponseCache definir o elemento `<UseResponseCacheHeaders>` como `true`, a resposta pode ser colocada em cache durante o número de segundos especificado por esta diretiva. Esta diretiva é substituída pela diretiva `s-maxage` e substitui o cabeçalho `Expires`. Também pode ser substituído pelo elemento `<ExpirySettings>` da política. Para mais informações, consulte "Definir a expiração da entrada de cache" e `<UseResponseCacheHeaders>` em Política de cache de respostas. Nota: o conteúdo em cache com a política ResponseCache retém o valor de idade máxima definido pela respetiva origem. Isto significa que, quando obtido a partir da cache, o conteúdo pode ser mais antigo do que o valor max-age sugere (mais antigo do que o cliente sabe).
`must-revalidate`	Não suportado. Todas as entradas da cache são eliminadas pelo Apigee assim que expiram.
`no-cache`	O Apigee armazena em cache a resposta de origem, mas tem de ser revalidada com o servidor de origem antes de ser usada para satisfazer quaisquer pedidos de clientes subsequentes. Esta regra permite que a origem devolva uma resposta 304 Not Modified para indicar que a resposta deve ser devolvida a partir da cache, poupando assim o processamento necessário para devolver a resposta completa. Se o servidor de origem devolver uma resposta completa, substitui a entrada de cache existente. Todos os nomes de campos especificados com esta diretiva são ignorados. Nota: o cabeçalho HTTP/1.0, `Pragma: no-cache`, é tratado como equivalente a `Cache-Control: no-cache`.
`no-store`	Não suportado.
`no-transform`	Não suportado.
`private`	Não suportado. Se esta diretiva for recebida, a resposta de origem não é colocada em cache. Os nomes dos campos são ignorados.
`proxy-revalidate`	Não suportado. Todas as entradas da cache são eliminadas pelo Apigee assim que expiram.
`public`	O Apigee 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 esta regra é se a resposta incluir um cabeçalho de autorização.
`s-maxage`	Se a sua política ResponseCache definir o elemento `<UseResponseCacheHeaders>` como `true`, a resposta pode ser colocada em cache durante o número de segundos especificado por esta diretiva. Esta diretiva substitui a diretiva `max-age` e o cabeçalho `Expires`. Pode ser substituído pelo elemento `<ExpirySettings>` da política. Para mais informações, consulte "Definir a expiração da entrada de cache" e `<UseResponseCacheHeaders>` em Política de cache de respostas. Nota: o conteúdo em cache com a política ResponseCache retém o valor s-maxage definido pela respetiva origem. Isto significa que, quando obtido a partir da cache, o conteúdo pode ser mais antigo do que o valor de s-maxage sugere (mais antigo do que o cliente sabe).

Expira em

Quando a flag UseResponseCacheHeaders na política ResponseCache está definida como true, o Apigee pode usar o cabeçalho Expires para determinar o tempo de vida (TTL) de uma entrada em cache. Este cabeçalho especifica uma data/hora após a qual a entrada da cache de uma resposta é considerada obsoleta. Este cabeçalho permite que os servidores sinalizem quando é aceitável devolver um valor em cache com base numa indicação de tempo.

Nota: as diretivas de cabeçalho Cache-Control max-age e s-maxage têm precedência e substituem o cabeçalho Expires. Para mais informações, consulte "Definir a expiração da entrada da cache" e <UseResponseCacheHeaders> em Política de cache de respostas.

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

Expira: Qui, 01 de dez. de 1994 16:00:00 GMT

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

Nota: embora a secção 14.21 da especificação indique que um valor Expires superior a um ano no futuro significa que uma entrada na cache nunca expira, o Apigee interpreta esse valor como significando que a entrada deve ser colocada em cache até à data e hora especificadas.

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

ETag

Uma etiqueta de entidade (ETag) é um identificador associado a um recurso pedido. Usando uma ETag, um servidor pode determinar se o recurso pedido e o recurso em cache associado correspondem. Por exemplo, o servidor pode voltar a colocar a resposta em cache se não corresponder ao que está atualmente em cache. Pode devolver o recurso em cache se as ETags corresponderem.

Quando um ponto final de destino envia uma resposta de volta para o Apigee com um ETag, o Apigee armazena o ETag em cache juntamente com a resposta.

Pode ler mais acerca das etiquetas de entidade nos parâmetros do protocolo na especificação HTTP/1.1.

If-Match

Com o cabeçalho de pedido If-Match, uma entidade em cache está atualizada se o ETag no cabeçalho corresponder ao ETag em cache. Todos os pedidos que não sejam GET e que especifiquem um cabeçalho If-Match são transmitidos ao servidor de origem para garantir que todas as instalações de colocação em cache de origem têm a possibilidade de processar o pedido.

Pode ler mais acerca de If-Match em Definições do campo de cabeçalho na especificação HTTP/1.1.

Se o Apigee receber um pedido GET de entrada de um cliente que inclua um cabeçalho If-Match:

Se	Depois
O cabeçalho `If-Match` especifica uma ou mais ETags	O Apigee obtém todas as entradas de cache não expiradas para o recurso especificado e compara todas as ETags fortes nessas entradas em cache com as especificadas no cabeçalho `If-Match`. Se for encontrada uma correspondência, é devolvida a entrada da cache. Caso contrário, o pedido é transmitido para o servidor de origem.
O cabeçalho `If-Match` especifica "*"	O pedido é transmitido ao servidor de origem para garantir que todas as instalações de colocação em cache de origem têm a oportunidade de processar o pedido
É encontrada uma entrada de cache com o mesmo URI de pedido, mas contém apenas ETags fracos	A entrada tem de ser revalidada pelo servidor de origem antes de ser devolvida ao cliente
As ETags provêm do servidor de origem.	O ETag é devolvido inalterado ao cliente

If-None-Match

Com o cabeçalho If-None-Match, uma entidade em cache está atual se o ETag no cabeçalho não corresponder ao ETag em cache. Os pedidos que não sejam um GET e que contenham este cabeçalho são transmitidos ao servidor de origem.

Se o Apigee receber um pedido GET de entrada com este cabeçalho:

Se	Depois
O cabeçalho `If-None-Match` especifica uma ou mais ETags	O Apigee obtém todas as entradas de cache não expiradas para o URI especificado e compara todas as ETags fortes nessas entradas em cache com as especificadas no cabeçalho `If-None-Match`. Se for encontrada uma correspondência, o Apigee devolve um estado 304 Not Modified. Se não for encontrada nenhuma correspondência, o Apigee passa o pedido para o servidor de origem.
O cabeçalho `If-None-Match` especifica "*" e existe uma entrada em cache não expirada para o URI pedido	O Apigee devolve um estado 304 Not Modified
Foi encontrada uma entrada de cache com o mesmo URI de pedido, mas contém apenas ETags fracos	A entrada tem de ser revalidada pelo servidor de origem antes de o Apigee a devolver ao cliente
O Apigee recebe uma ETag de um servidor de origem	O ETag é devolvido inalterado ao cliente

If-Modified-Since

Se o Apigee receber um cabeçalho If-Modified-Since num pedido GET, este é transmitido ao servidor de origem, mesmo que exista uma entrada de cache válida.

Isto garante que quaisquer atualizações a um recurso que não passou pelo Apigee são tidas em conta. Se o servidor de origem devolver uma nova entidade, o Apigee substitui a entrada da cache existente pelo novo valor. Se o servidor devolver um estado 304 Not Modified, o Apigee devolve o valor de resposta se o cabeçalho Last-Modified da resposta em cache indicar que não foi alterado.

Accept-Encoding

Quando um pedido recebido inclui o cabeçalho Accept-Encoding com valores de gzip, deflate ou compress, o servidor de origem responde com dados comprimidos. Quando os pedidos subsequentes chegam sem os cabeçalhos Accept-Encoding, os clientes esperam uma resposta não comprimida. O mecanismo de colocação em cache de respostas do Apigee é capaz de enviar respostas comprimidas e não comprimidas, consoante os cabeçalhos recebidos, sem voltar ao servidor de origem.

Pode ter valores do cabeçalho Accept anexados às chaves de cache para tornar as chaves mais significativas para cada item em cache. Para mais detalhes, consulte "Configurar uma chave de cache" na política de cache de respostas.