-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 14.10.2016 0:28, Alex Rousskov пишет: > On 10/13/2016 11:52 AM, Yuri Voinov wrote: >> When we seen ??????/304 with only headers - most probably content behind >> proxy already and this is CLIENT_IMS_HIT observed. >> >> Yes, of course, we don't know is this content really in client cache. >> But this is don't care - proxy shared cache contains not modified copy >> of content. >> >> Right? > > Wrong. > > A 304 code sent by Squid to the client means "Squid told the client that > the client has a fresh copy (or equivalent)". It does not tell us how > Squid came up with that answer, or what Squid has in its cache: We do > not know whether Squid had the corresponding entry cached when the > client request came. If Squid had that entry cached, then Squid may or > may not have tried to validate it. If Squid tried to validate, then > Squid may or may not have gotten an entry from the origin server. > Finally, we do not know whether Squid kept, replaced, or deleted the > cache entry as the result of that validation attempt. > > For an extreme example, consider Squid without a cache. Such a > configuration will still have lots of /304 entries in access.log! > > A single access.log line (and often even a single Squid result code on > that line!) is telling us what happened when Squid talked to the client > _and_ what happened when Squid talked to the server (if it did talk to > the server). One cannot gain that vital information from a single HTTP > status code alone. > > > Many folks disagree regarding the best way to structure Squid result > codes. Many also disagree regarding the best definition for "cache hit". > All the different approaches make it very difficult to discuss these > matters and maintain related code. A /304 field alone means the client > got an HTTP 304 response. Whether you call that a "hit" from Squid point > of view depends on your definition of "hit" _and_ (depending on that > definition) on other factors that /304 does not reveal. For example: > > * if your definition of a "hit" is "Squid did not talk to the origin > server or peer", then /304 alone does not necessarily mean a hit. But most probably, right? > > > * if your definition of a "hit" is "Squid did not receive a large > response from the origin server or peer", then /304 alone does not > necessarily mean a hit. But still most probably, yes? Alone - agreed, Alex. But we've can see all transaction, right? So, if we've already done request to the same URL in the past, got TCP_MISS, then get again, _and_ has saved copy in cache, _and_ we're got 304 - this is hit. For shared cache itself. We're not consider cases of HTTP violations - we're respect RFC. :) But: If something behaves like a hit, it looks like a hit and quacks like a hit - it hit. :) > > > > HTH, > > Alex. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX/9aGAAoJENNXIZxhPexGBOMH/iz2NXmTfcVrCMq0Do2sOz2M ndhc1Pi60HoLYle9zgKfBA4qS5ozHuUyVN96IYcCtu0y/2+IxhnAoliSUTveQTjm 06tXcQtq+6fsEJNmLsF/cMPO3cFGlp8zbjup1P94S8yNyKbsjXGgyWyCIlOtEqT4 uaMRG2dDCx2XzdvLOpW92XSKn6jeF8dYMhLSQy3offbkPoabqQXTyNo+vvZCR4gE jhtGhLMCFW4/GD1RoDPdI0Gf+4sKdMtOlP5KrS4BCebQ+HQeCKGTnbpbr46wEVWy PbF1dCnl9REH6Q/sNCXmRwxImFr89Go8VWvzugigGktlRsMM01VFEEIqjzlCQuw= =47G3 -----END PGP SIGNATURE-----
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
