[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-----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-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161014/3a7723d5/attachment-0001.key>