[Fwd: Antwort: [Mod_gzip] Vary: header and mod_gzip]

-----Forwarded Message-----

> From: Michael.Schroepl@telekurs.de
> To: mod_gzip@lists.over.net
> Cc: robertc@squid-cache.org
> Subject: Antwort: [Mod_gzip] Vary: header and mod_gzip
> Date: 26 Aug 2002 15:35:03 +0200
>
>
> Hi Robert,
>
>
> > I'm one of the squid (www.squid-cache.org) proxy & cache developers.
>
> I am very happy that someone like you is showing up here.
> Obviously the problem you mention is around and there should
> be some cooperation and information exchange to solve it,
> even beyond simply adding the missing "Vary:" header to the
> mod_gzip output.
>
> I am not using Squid myself but have read some parts of the
> manuals which told me that from some Squid version on (2.4?)
> Squid decided to not cache content with a "Vary:" header.
> This would solve the data integrity problem but disable the
> caching feature of Squid and thus cause a severe performance
> problem for high-traffic sites. So there might be more to do
> than just disable caching compressed content.
>
> You may be the perfect guy to proof-read
> http://www.schroepl.net/projekte/mod_gzip/cache.htm
> (which is now - finally! - completely translated to English,
> sigh) and tell me whether I might have understood the caching
> problem and all of its aspects and which parts of my page
> should be corrected and/or improved.
>
> > This is the scenario: A user behind a proxy requests a page from a
> > mod_gzip enabled server. The proxy caches the result according to
> > RFC 2616 rules. A second user, using a non-compress enabled browser
> > (i.e. older netscapes, older text browsers, or apparently recent
> > Mac browsers) requests the same document, and the proxy (again in
> > conformance with RFC 2616) returns the cached object - which the
> > client can not interpret.
>
> The second user may even use the best browser in the world
> and will still not be able to understand the response in
> some cases.
> A user may disable sending "Accept-Encoding: gzip" in both
> Mozilla (explicitly) and M$IE (by setting the HTTP-level to
> 1.0), and both browsers will _then_ refuse to decompress
> content-encoded pages, although they are able to do so ("I
> didn't order it, so why should I now handle it?").
> Please have a look at
> http://www.schroepl.net/projekte/mod_gzip/browser.htm
> for the details.
> So the problem is even worse than you describe it, because
> many M$IE users may have their Internet Options set to
> HTTP/1.0, possibly even without knowing or by decision of
> their company admins.
>
> > This occurs because mod_gzip is not setting a Vary: header in the reply.
>
> Right.
>
> I myself use "mod_headers" to explicitly send the "Vary:"
> header in these cases as a workaround, and additionally send
> "Cache-Control: Private", both of these in combination with
> <FilesMatch> sections, having one <FilesMatch> for each
> "mod_gzip_item_include file" directive.
> This means I need to somehow configure all the file types
> twice in my Apache configuration, but I am doing this anyway
> as these <FilesMatch> sections contain other directives as
> well, like hand-tailored "Expires:" headers for individual
> file types that change with different frequencies on my server.
>
> I encourage every Apache user to do the same until some future
> mod_gzip version will solve the problem.
>
> > (See RFC 2616 section 14.44, and 14.3). Setting 'Vary: Accept-Encoding'
> > is a SHOULD requirement of RFC 2616 when using Server driven negotiation.
>
> Yes, unfortunately.
> I wish it were a MUST because then mod_gzip would simply
> violate the HTTP standard and this problem might never have
> been occurred as Kevin would then surely have done it right.
> As my article describes, mod_gzip isn't just "playing fair" to
> Squid as it doesn't even warn it about the potential problem
> - but it doesn't really violate HTTP/1.1 as well.
>
> But the real problem seems to be that a correct "Vary:" header
> should contain _all_ the HTTP headers that are subject to
> negotiation, which would then enable Squid to even do the
> negotiation itself in some cases.
> Unfortunately, the structure of mod_gzip doesn't allow for this,
> as it is doing negotiation on things that are _not_ part of the
> HTTP header, so it seems to be impossible to express in the
> "Vary:" header what mod_gzip _really_ did.
>
> Only some days ago we had a discussion here where I tried to
> outline a concept where mod_gzip compression an Squid caching
> could even be used in combination - I will forward the mail
> to you separately. My idea would have required a third piece
> of software, but maybe this one could even be a part of Squid
> itself - at least we should look at it together more closely.
>
> > I've grepped the mod_gzip sources, but could not see any reference to
> > Vary.
>
> Correct.
>
> > Is there somewhere for the users of mod_gzip to lodge a bug report on
> > this? Or is it trivial enough for a mod_gzip hacker to fix that I'll
> > get a reply "Hey, we overlooked this, it's fixed now"? :}.
>
> I already have this on my list, and I am optimistic that there
> will be a solution to it in the near future. But sadly, the
> number of "mod_gzip hackers" is very close to zero these days.
>
> Greetings, Michael
>
>