Até hoje, acredito que ainda não há proxies que suportem totalmente essa especificação HTTP. Então, há cerca de um ano, decidi escrever meu próprio usando o Node.js e o MongoDb.
Estou desenvolvendo um sistema de cache para uma plataforma de comércio eletrônico que usará um proxy reverso para armazenamento em cache. Eu pretendo lidar com invalidação usando cabeçalhos HTTP / 1.1 adequados. Ou seja, configurarei um ETag na primeira geração do conteúdo e armazenarei em cache esse valor de ETag no aplicativo. O cabeçalho Cache-Control especificará "must-revalidate" para que o proxy defina o cabeçalho If-None-Match nas solicitações subseqüentes com o ETag. O aplicativo pesquisará o valor da ETag em cache e, se ele corresponder, enviará uma resposta 304, caso contrário, gerará uma resposta completa de 200.
Eu esperava usar o nginx, mas não posso dizer com certeza que ele suporta ETags (docs indicam que não, mas talvez eles estejam desatualizados?). O verniz é outra opção, mas também não sou positivo aqui.
Quais servidores proxy reversos têm suporte total para ETags? Gostaria de armazenar em cache várias versões para que eu possa fazer coisas como dividir o teste sem precisar desativar o cache. Ou seja, HTTP / 1.1 especifica que um cliente pode enviar If-None-Match com vários valores de ETag e o servidor deve responder com qual ETag correspondeu (se houver). Se o proxy reverso mantivesse várias cópias em vez de apenas o último valor visto e deixasse o servidor especificar em cada requisição qual usar, isso seria ideal.
Até hoje, acredito que ainda não há proxies que suportem totalmente essa especificação HTTP. Então, há cerca de um ano, decidi escrever meu próprio usando o Node.js e o MongoDb.
Acabei de verificar o código-fonte em Varnish e, embora suporte If-Modified-Since e If-None-Match cabeçalhos, ele não suporta must-revalidate em Cache-Control . Os únicos atributos suportados em Cache-Control são max-age e s-max-age .
Referências:
bin/varnishd/cache/cache_rfc2616.c em RFC2616_Do_Cond ()
bin/varnishd/cache/cache_rfc2616.c em RFC2616_Ttl () include/tbl/http_headers.h O nginx requer módulos de terceiros para suportar o ETag. E há dois deles.
Corrija-me se estiver errado e sei que este é um post antigo, mas gostaria de comentar para os novos transeuntes. Acredito que um cache de proxy reverso não ajuda tanto quanto você gostaria ao usar ETags.
Mecanismos de armazenamento em cache de validação usam o servidor de origem para validar se a ETag (ou data da última modificação) na solicitação ainda é válida (corresponde ou não aos recursos etag, dependendo de qual cabeçalho é usado ou tem / tem não foi modificado desde a data indicada no pedido).
Isso significa que um cache de proxy reverso, como o Varnish, ainda passará essa solicitação para o servidor de origem. Ele pode responder com a solicitação em vez de fazer com que o servidor a manipule, mas você não salvou a ida e volta ao servidor de origem.
Os navegadores podem armazenar respostas em cache e lidar com uma resposta 304 em qualquer caso, portanto o cache privado do usuário pode ser mais adequado para lidar com isso do que usar um proxy reverso (YMMV, especialmente em escala e dependendo do seu caso de uso. não quero fazer suposições sobre seus aplicativos).
Da especificação 13.3 :
When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the HTTP/1.1 protocol supports the use of conditional methods.
e, em seguida, observe 13.3.4 :
An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity tags as cache validators, MUST NOT return a locally cached response to the client unless that cached response is consistent with all of the conditional header fields in the request.
Assim, o Varnish pode retornar uma resposta para você, mas você ainda tem uma ida e volta para o servidor. Se você pode usar um cache de aplicativos, como APC ou memcache, então isso pode valer a pena para você. O armazenamento em cache de validação geralmente é melhor para economia de largura de banda em relação à economia de recursos do servidor.
O armazenamento em cache de validação pode ser melhor deixado para o cliente (navegador ou código da API).
Usar o modelo Expiration para armazenamento em cache é onde um cache de proxy reverso realmente brilha. Isso permite que você pule totalmente o servidor de origem. Usar Expires , Cache-Control , Date , etc, é o melhor (novamente, IMO) mecanismo para um cache de proxy reverso, pois o cache pode retornar a resposta, assumindo que ela não é obsoleta, sem nunca atingir o servidor de origem. / p>
Você pode ver o Apache TrafficServer , que parece tenha o que você precisa .
Tags nginx reverse-proxy http varnish etags