Re: [squid-users] headers say HIT, logs say MISS, payload is truncated...

On mån, 2008-10-27 at 15:56 -0700, Neil Harkins wrote:

> I'd like to help and see this get fixed, but as I said earlier,
> it happens on about 16% of our test requests, only when
> there's 750~1050 reqs/second going through the box,
> and pretty much disappears under 500 reqs/s (off-peak).

Ouch..

> Is this except significant?:

Hard to say, but probably not. It's just reading of the Vary/ETag index,
finding that the request matches the object with key
968D51EAA0C2BCF5688EAB92E8F56EE4.

Do your server support ETag on these objects? And do it properly report
different ETag values for the different variants? Or are you using
broken_vary_encoding to work around server brokenness?

> Note that I've since changed our load balancer to rewrite "Accept-Encoding: "
> to "Accept-Encoding: identity" in case squid didn't like a null header,
> (although the example in the RFC implies that "Accept-Encoding: " is valid:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3)
> but the timeouts still happened, although I didn't grab debugging then.

Accept-Encoding header without a value is not really a valid HTTP header
(what you probably want is no Accept-Encoding header at all). But Squid
should work fine in both cases as it's just two different Vary request
fingerprints.

The blank example is an error in the specifications descriptive text and
has been corrected in the errata.

If you look closely at the above reference you'll notice the BNF says
1#(...) which means at least one. The BNF is the authorative definition
of the syntax of this header, the rest of the text just tries to explain
it..

Regards
Henrik