is this bug or its made to work like that
lets say we have object in cache name 000000A5
url.com/some.js
vary=accept-encoding="gzip"
if some browser get the same object
url.com/some.js
vary=accept-encoding="deflate"
the md5 key wont match and it delete the old cached object with
accept-encoding="gzip" and replace with
new one with vary=accept-encoding="deflate" and prosess as TCP_MISS
that will result in "varyEvaluateMatch: Oops. Not a Vary match on second
attempt
no match and the code in client_side.cc
return VARY_CANCEL
and in client_side_reply.cc
case VARY_CANCEL:
/* varyEvaluateMatch found a object loop. Process as miss */
debugs(88, DBG_IMPORTANT, "clientProcessHit: Vary object loop!");
http->logType = LOG_TCP_MISS; // we lack a more precise LOG_*_MISS
code
processMiss();
return;
the way it should be instead of replacing the existing obj should be
another object with the
new vary
shuld be 2 file 000000A5
and 000000A6 example each one has different vary to match the correct
obj if its gzip or ident or deflate or with useragent
wen vary not matching shuld be new obj file to be saved as diferent cache
name 000000A7
so it match the correct object name with its vary
--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/cache-object-with-vary-tp4679220.html
Sent from the Squid - Users mailing list archive at Nabble.com.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
