I'm not proposing a solution but just pointing out that if this discussion is going to come up once again that even the latest, greatest versions of one of the most popular browsers in the world, Microsoft Internet Explorer, will still REFUSE TO CACHE any response that shows up with a "Vary:" on any field other than "User-Agent". It is certainly true that using the same ETag for two different "Variants" is in violation of RFC, but just fixing ETag isn't going to fully solve the industry-wide problem. The moment the user-agent itself it refusing to cache responses that have any "Vary:" conditions at all then you create a "thundering herd" scenario now on the "last mile" instead of between Proxy/COS ( Content Origin Server ). The long-running question will still remain. Is it better to at least have the user-agents hanging on to non-expired responses that have actually been CACHED locally and not hammering the proxies at all, or it is it simply better to have the proxy do the heavy-breathing if/when a lot of requests are coming for a document that might have two ( varied ) responses. In the case of "Accept-encoding: gzip", it's pretty darn rare these days for any COS or Proxy to ever get a reqeust from some brain-dead user-agent that can't decompress, isn't it? Hasn't the non-compressed variant become an extreme edge-case by now? I would certainly hope so. Yours Kevin Kiley In a message dated 8/27/2007 5:33:55 AM Pacific Standard Time, [EMAIL PROTECTED] writes:
Just wondering if there is any plans on addressing Bug #39727, incorrect ETag on gzip:ed content (mod_deflate). Been pretty silent for a long while now, and the current implementation is a clear violation of RFC2616 and makes a mess of any shared cache trying to cache responses from mod_deflate enabled Apache servers (same problem also in mod_gzip btw..) For details about the problem this is causing see RFC2616 section 13.6, pay specific attention to the section talking about the use of If-None-Match and the implications of this when a server responds with the same ETag for the two different variants of the same resource. There is already a couple of proposed solutions, but no concensus on which is the bettter or if any of them is the proper way of addressing the issue. The problem touches - ETag generation - Module interface - Conditionals processing when there is modules altering the content Squid currently have a kind of workaround in place for the Apache problem, but relies on being able to detect broken Apache servers by the precense of Apache in the Server: header, which isn't fool prof by any means. Regards Henrik ************************************** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour
