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.

Version: GnuPG v2

Attachment: 0x613DEC46.asc
Description: application/pgp-keys

squid-users mailing list

Reply via email to