fre 2006-12-08 klockan 15:35 -0800 skrev Justin Erenkrantz: > As Kevin mentioned, Squid is only using the ETag and is ignoring the > Vary header. That's the crux of the broken behavior on their part. > If they want to point out minor RFC violations in Apache, then we can > play that game as well. (mod_cache deals with this Vary/ETag case > just fine, FWIW.)
We are not at all ignoring Vary, but we are using If-None-Match to ask the server which one of the N already cached entities belonging to the resource URI is valid for this specific request, indirectly learning the server side content negotiation logics used. > The compromise I'd be willing to accept is to have mod_deflate support > the 'TE: gzip' request header and add 'gzip' to the Transfer-Encoding > bit - and to prefer that over any Accept-Encoding bits that are sent. Would be a great move if you can not make it behave correct in the content space. But if you make mod_deflate behave according to the RFC then sending Content-Encoding: gzip is fine to me. But TE is a much better fit from the RFC point of view. > The ETag can clearly remain the same in that case - even as a strong > ETag. Yes. > So, Squid can change to send along TE: gzip (if it isn't > already). TE: gzip is likely to appear in 3.1. > And, everyone else who sends Accept-Encoding gets the > result in a way that doesn't pooch their cache if they try to do a > later conditional request. As long as mod_deflate continues ignoring the RFC wrt ETag there will conflicts with various cache implementations. > Is that acceptable? -- justin Intentionally not following a MUST level requirements in the RFC is not an acceptable solution in my eyes. For one thing even if you ignore everyone else it would make it impossible for Apache + mod_deflate to claim RFC 2616 HTTP/1.1 compliance. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
