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
Attachment:
signature.asc
Description: This is a digitally signed message part
