[Mod_gzip] "mod_gzip_send_vary=Yes" disables caching on IE? (1.3.26.1a)

Fri, 6 Dec 2002 19:26:09 EST

--part1_1a9.d2ffbef.2b229a21_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 12/6/2002 5:55:16 PM Central Standard Time, 
jr-list-mod_gzip@quo.to writes:

> Could mod_gzip suppress the "Vary: Accept-Encoding" header when sending back
> uncompressed data? That seems like the perfect "solution".
> 

It could... but that is still not 'the perfect solution'.

What could happen then is that the original 'problem' 
re-surfaces and if there is a Caching-Proxy ( like SQUID )
anywhere between you and the origin Server then it
will NOT have been told that request for that page
can 'Vary:'.

This is one of those 'all or nothing' deals where unless
EVERYTHING between you and the Server is fully
HTTP 1.1 compliant then something is going to 
screw up somewhere.

When it comes to following the 'principles of least
astonishment' upon which the authors of HTTP
itself based their work... I would say that just 
leaving "Vary:" out of the picture altogether and
focusing on whatever problems remain with 
ancient Non-HTTP compliant browsers still being
unable to 'Accept-Encoding' and/or people simply
refusing to upgrade thier ancient browsers would
be just as simple a focus as trying to make sure 
that everything is able to play the "Vary:" game.

In other words... if it's time to start fixing what is
'broken' out there then why not focus on the original
issue which is that all modern browsers can/do
send 'Accept-Encoding: gzip' and SHOULD be able
to do just that at all times. There are no ifs/ands
or buts in that HTTP request header. If a browser
sends it at all then it is NOT 'mime type specific'
and the browser SHOULD be able to 'decode'
ANY mime type that the Server will return...
no questions asked.

If there is ANY mime type that is going to be
'screwed up' by the browser if it comes back with
'Content-Encoding: gzip' then the browser has
no business ever sending "Accept-Encoding: gzip"
in the first place.

The authors of HTTP did not allow this to be a
'conditional' signal. It's ALL ( Mime types ) or NOTHING.

Yours...
Kevin Kiley

--part1_1a9.d2ffbef.2b229a21_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2><BR>
In a message dated 12/6/2002 5:55:16 PM Central Standard Time, jr-list-mod_gzip@quo.to writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Could mod_gzip suppress the "Vary: Accept-Encoding" header when sending back<BR>
uncompressed data? That seems like the perfect "solution".<BR>
</BLOCKQUOTE><BR>
<BR>
It could... but that is still not 'the perfect solution'.<BR>
<BR>
What could happen then is that the original 'problem' <BR>
re-surfaces and if there is a Caching-Proxy ( like SQUID )<BR>
anywhere between you and the origin Server then it<BR>
will NOT have been told that request for that page<BR>
can 'Vary:'.<BR>
<BR>
This is one of those 'all or nothing' deals where unless<BR>
EVERYTHING between you and the Server is fully<BR>
HTTP 1.1 compliant then something is going to <BR>
screw up somewhere.<BR>
<BR>
When it comes to following the 'principles of least<BR>
astonishment' upon which the authors of HTTP<BR>
itself based their work... I would say that just <BR>
leaving "Vary:" out of the picture altogether and<BR>
focusing on whatever problems remain with <BR>
ancient Non-HTTP compliant browsers still being<BR>
unable to 'Accept-Encoding' and/or people simply<BR>
refusing to upgrade thier ancient browsers would<BR>
be just as simple a focus as trying to make sure <BR>
that everything is able to play the "Vary:" game.<BR>
<BR>
In other words... if it's time to start fixing what is<BR>
'broken' out there then why not focus on the original<BR>
issue which is that all modern browsers can/do<BR>
send 'Accept-Encoding: gzip' and SHOULD be able<BR>
to do just that at all times. There are no ifs/ands<BR>
or buts in that HTTP request header. If a browser<BR>
sends it at all then it is NOT 'mime type specific'<BR>
and the browser SHOULD be able to 'decode'<BR>
ANY mime type that the Server will return...<BR>
no questions asked.<BR>
<BR>
If there is ANY mime type that is going to be<BR>
'screwed up' by the browser if it comes back with<BR>
'Content-Encoding: gzip' then the browser has<BR>
no business ever sending "Accept-Encoding: gzip"<BR>
in the first place.<BR>
<BR>
The authors of HTTP did not allow this to be a<BR>
'conditional' signal. It's ALL ( Mime types ) or NOTHING.<BR>
<BR>
Yours...<BR>
Kevin Kiley<BR>
</FONT></HTML>
--part1_1a9.d2ffbef.2b229a21_boundary--