Como o mod_cache trabalha com “must-revalidate” e “max-age”?

4

Pergunta rápida antes de eu explicar meu fluxo: Сum mod_cache executa revalidate com if-none-match apenas se max-age expirar caso seja configurado no modo de proxy reverso?

Meu objetivo é reduzir várias solicitações de revalidação para o nosso servidor de origem.

Por exemplo: A primeira requisição vai para o servidor de origem e então mod_cache salva uma resposta no cache de acordo com o cabeçalho cache-control: max-age. E somente quando a duração máxima estiver expirada, mod_cache será revalidado com if-none-match.

Atualmente, mod_cache revalida cada solicitação, independentemente de a duração máxima estar definida ou não.

Minha configuração do Apache 2.4.3 (Windows), no linux eu vejo o mesmo comportamento que mostrarei abaixo.

    
   ServerName proxy.lo
   ProxyRequests Off    
   ProxyPreserveHost Off

   Header set Vary "Accept, Content-Type, Content-Encoding, Accept-Language"

   RequestHeader set X-Forwarded-Proto "http"

   # modify header for user agent's
   Header set Cache-Control "private, no-cache, no-store, no-transform"

   CacheQuickHandler off

   CacheDefaultExpire 300

   # the origin server do not provide last-modified
   CacheIgnoreNoLastMod On
   CacheIgnoreCacheControl On

   # the origin server define cache-control: private, no-store only for user agents
   # Therefore, I would like ignore those headers on the proxy server.
   CacheStorePrivate On
   CacheStoreNoStore On

   CacheEnable disk /
   CacheRoot "C:/Apache.Cache" 
   CacheDirLevels 5
   CacheDirLength 4 

   CacheMinExpire 15

   CacheDetailHeader on
   CacheHeader on

   KeepAlive Off

   ProxyPass / http://origin.lo/
   ProxyPassReverse / http://origin.lo/

Além disso, ativei o nível de log de depuração para ver como o mod_cache manipula um conteúdo para armazenamento em cache: Eu forneci isso para mostrar que o mod_proxy sempre decide que um conteúdo não é novo. Por que? Eu forneci isso para mostrar que o mod_proxy sempre decide que um conteúdo não é novo. Por quê? max-idade foi fornecida (veja abaixo).

[Sun Nov 04 11:58:42.899890 2012] [cache:debug] [pid 6492:tid 1400] cache_storage.c(624): [client 192.168.1.100:63741] AH00698: cache: Key for entity /testpage?(null) is http://proxy.lo/testpage?
[Sun Nov 04 11:58:42.899890 2012] [cache_disk:debug] [pid 6492:tid 1400] mod_cache_disk.c(569): [client 192.168.1.100:63741] AH00709: Recalled cached URL info header http://proxy.lo/testpage?
[Sun Nov 04 11:58:42.899890 2012] [cache_disk:debug] [pid 6492:tid 1400] mod_cache_disk.c(865): [client 192.168.1.100:63741] AH00720: Recalled headers for URL http://proxy.lo/testpage?
[Sun Nov 04 11:58:42.899890 2012] [cache:debug] [pid 6492:tid 1400] cache_storage.c(320): [client 192.168.1.100:63741] AH00695: Cached response for /testpage isn't fresh.  Adding/replacing conditional request headers.
[Sun Nov 04 11:58:42.899890 2012] [cache:debug] [pid 6492:tid 1400] mod_cache.c(414): [client 192.168.1.100:63741] AH00757: Adding CACHE_SAVE filter for /testpage
[Sun Nov 04 11:58:42.899890 2012] [cache:debug] [pid 6492:tid 1400] mod_cache.c(448): [client 192.168.1.100:63741] AH00759: Adding CACHE_REMOVE_URL filter for /testpage
[Sun Nov 04 11:58:42.899890 2012] [proxy:debug] [pid 6492:tid 1400] mod_proxy.c(1068): [client 192.168.1.100:63741] AH01143: Running scheme http handler (attempt 0)
[Sun Nov 04 11:58:42.899890 2012] [proxy:debug] [pid 6492:tid 1400] proxy_util.c(1976): AH00942: HTTP: has acquired connection for (origin.lo)
[Sun Nov 04 11:58:42.899890 2012] [proxy:debug] [pid 6492:tid 1400] proxy_util.c(2029): [client 192.168.1.100:63741] AH00944: connecting http://origin.lo/testpage to origin.lo:80
[Sun Nov 04 11:58:42.901890 2012] [proxy:debug] [pid 6492:tid 1400] proxy_util.c(2151): [client 192.168.1.100:63741] AH00947: connected /testpage to origin.lo:80
[Sun Nov 04 11:58:42.901890 2012] [proxy:debug] [pid 6492:tid 1400] proxy_util.c(2554): AH00962: HTTP: connection complete to 192.168.1.100:80 (origin.lo)
[Sun Nov 04 11:58:42.903890 2012] [proxy:debug] [pid 6492:tid 1400] proxy_util.c(1991): AH00943: http: has released connection for (origin.lo)
[Sun Nov 04 11:58:42.903890 2012] [headers:debug] [pid 6492:tid 1400] mod_headers.c(800): AH01502: headers: ap_headers_output_filter()
[Sun Nov 04 11:58:42.903890 2012] [cache:debug] [pid 6492:tid 1400] mod_cache.c(1190): [client 192.168.1.100:63741] AH00769: cache: Caching url: /testpage
[Sun Nov 04 11:58:42.903890 2012] [cache:debug] [pid 6492:tid 1400] mod_cache.c(1196): [client 192.168.1.100:63741] AH00770: cache: Removing CACHE_REMOVE_URL filter.
[Sun Nov 04 11:58:42.904890 2012] [cache_disk:debug] [pid 6492:tid 1400] mod_cache_disk.c(1318): [client 192.168.1.100:63741] AH00737: commit_entity: Headers and body for URL http://proxy.lo/testpage? cached.

A primeira solicitação para o servidor de origem sem o mod_proxy para o link

GET http://origin.lo/testpage HTTP/1.1
Host: origin.lo
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Accept: application/json
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

A primeira resposta da origem sem mod_proxy

HTTP/1.1 200 OK
Cache-Control: must-revalidate, proxy-revalidate, max-age=30
Content-Type: application/json; charset=utf-8
ETag: "7cf651e2-176f-4ac1-808e-0e0c17cfd0a2"
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sun, 04 Nov 2012 10:11:01 GMT
Content-Length: 1877

Então, eu assumi que a revalidação deve ocorrer somente em 30 segundos após a resposta de sucesso. Não está certo?

Vamos verificar:)

Em 30 segundos, o Google Chrome não realizou solicitações ao servidor de origem para revalidar uma solicitação e retornou a resposta do cache local.

Quando a duração máxima é expirada, o Google Chrome realiza uma solicitação para revalidar:

GET http://origin.lo/testpage HTTP/1.1
Host: origin.lo
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Accept: application/xml
If-None-Match: "7cf651e2-176f-4ac1-808e-0e0c17cfd0a2"
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

e resposta:

HTTP/1.1 304 Not Modified
Cache-Control: must-revalidate, proxy-revalidate, max-age=30
ETag: "7cf651e2-176f-4ac1-808e-0e0c17cfd0a2"
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sun, 04 Nov 2012 10:16:20 GMT

Como você pode ver, tudo funciona conforme o esperado. O agente do usuário revalida a solicitação apenas quando a duração máxima estiver expirada.

Vamos agora tentar executar o fluxo de foling através do mod_proxy (veja a configuração acima).

O primeiro pedido:

GET http://proxy.lo/testpage HTTP/1.1
Host: proxy.lo
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Accept: application/json
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

e a resposta foi:

HTTP/1.1 200 OK
Date: Sun, 04 Nov 2012 10:23:36 GMT
Server: Apache
Cache-Control: private, no-cache, no-store, no-transform
Content-Type: application/json; charset=utf-8
ETag: "7cf651e2-176f-4ac1-808e-0e0c17cfd0a2"
Content-Length: 1932
Vary: Accept,Content-Type,Content-Encoding,Accept-Language
X-Cache: MISS from proxy.lo
X-Cache-Detail: "cache miss: attempting entity save" from proxy.lo
Connection: close

Ok, vamos ver o cache de disco e tentar ver como a solicitação e a resposta foram armazenadas. (Eu cortei dados binários)

http://proxy.lo/testpage?
Cache-Control: private, no-cache, no-store, no-transform
Content-Type: application/json; charset=utf-8
ETag: "7cf651e2-176f-4ac1-808e-0e0c17cfd0a2"
Date: Sun, 04 Nov 2012 10:27:15 GMT
Content-Length: 1932
Vary: Accept, Content-Type, Content-Encoding, Accept-Language

Host: proxy.lo
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Accept: application/json
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
X-Forwarded-Proto: http
Cache-Control: max-age=300, must-revalidate
X-Forwarded-For: 192.168.1.100
X-Forwarded-Host: proxy.lo
X-Forwarded-Server: origin.lo

Ok, o que vemos? Vimos que o primeiro pedido foi realizado com max-age = 300 & deve-revalidar

Ok, parece bom, quanto a mim, vamos fazer a próxima ligação:

GET http://proxy.lo/testpage HTTP/1.1
Host: proxy.lo
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Accept: application/json
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

e a segunda resposta do mod_proxy:

HTTP/1.1 200 OK
Date: Sun, 04 Nov 2012 10:31:58 GMT
Server: Apache
Cache-Control: private, no-cache, no-store, no-transform
ETag: "7cf651e2-176f-4ac1-808e-0e0c17cfd0a2"
Content-Length: 1932
Vary: Accept,Content-Type,Content-Encoding,Accept-Language
X-Cache: REVALIDATE from proxy.lo
X-Cache-Detail: "conditional cache hit: entity refreshed" from proxy.lo
Connection: close
Content-Type: application/json; charset=utf-8

ASSIM, MINHA PERGUNTA É: POR QUE mod_proxy realiza a revalidação em cada solicitação, independentemente de que a max-age esteja definida?

N.B. Apache 2.4.3

Obrigado Eu ficaria muito grato por qualquer ajuda.

    
por Dmitriy Sosunov 04.11.2012 / 11:50

0 respostas