Estou usando o Apache 2.4.3 como um proxy reverso devido à conformidade anunciada com o RFC 2616. Meu aplicativo usa cabeçalhos como esse para ativar o armazenamento em cache no proxy:
Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: A
Vary: X-Group
ETag: W/"foo1"
Após a primeira solicitação aquecer o cache, se meu aplicativo mudar para responder com isso:
Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: B
Vary: X-Group
ETag: W/"foo2"
O aplicativo responderá com 304 Not Modified se o cabeçalho If-None-Match do Apache corresponder à ETag gerada pela origem. No entanto, o Apache, em seguida, armazena em cache a segunda resposta 200 e substitui o registro "foo1" com a nova resposta, em vez de armazenar em cache ambas as respostas com ETags diferentes. Portanto, em vez de If-None-Match: W/"foo1", W/"foo2" , a próxima solicitação de revalidação é apenas If-None-Match: W/"foo2" . Portanto, o cache está constantemente perdendo, em vez de sempre receber hits.
Do RFC 2616 seção 12.1:
However, an origin server is not limited to these dimensions and
MAY vary the response based on any aspect of the request, including
information outside the request-header fields or within extension
header fields not defined by this specification.
Eu tentei as seguintes combinações para Vary:
Vary: X-Foo
Vary: *
Vary: User-Agent
Eu também tentei ETags strongs e fracos e não importa o que eu não consigo fazer com que o Apache armazene em cache as duas respostas simultaneamente, sempre economiza sobre o anterior. Se não for possível salvar mais de uma variação de uma página, a ETag será inútil. A Última modificação será tão boa quanto.
Dos documentos do Apache 2.4:
mod_cache implements an RFC 2616 compliant HTTP content caching filter, with support for the caching of content negotiated responses containing the Vary header.
Note que diz "respostas" no plural. Estou interpretando erroneamente a especificação HTTP ou o Apache 2.4 simplesmente não suporta totalmente ETags depois de tudo?