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

Sat, 7 Dec 2002 03:26:10 EST

--part1_10e.1b3e139c.2b230aa2_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 12/7/2002 12:25:16 AM Central Standard Time, 
jr-list-mod_gzip@quo.to writes:

> > That was very similar issue with mod_deflate.
> 
> I checked the mod_deflate and also the PHP source code and it appears they
> do it the same way -- no Vary header unless sending gzipped content.
> 
> So it seems mod_gzip is alone in its sending of Vary headers for both
> gzipped and non-gzipped content?
> 
> Jordan Russell
> 
> 

So the assumption that PHP and mod_deflate are assuming
that the ONLY 'condition of variance' there could ever possibly
be with regards to delivering compressed/non-compressed
variants would be the "Accept-Encoding:' field?

That's a pretty dangerous ( and inflexible ) assumption to make.

It also means that if/when PHP/mod_deflate sends a compressed
response and that ONLY then do they add something like
"Vary: Accept-Encoding" or "Vary: User-Agent" then the ONLY
time the Proxy is ever going to check back with the original
server is if it current has the compressed version in its
cache ( with the "Vary:" directive associated with it ).

If the last person to ask for the page did NOT have 
"Accept-Encoding:" ( or whatever header it's supposed
to have according to whatever Vary: was sent )
then the Cache will now have an 'uncompressed' 
response stored but it will also NOT have any
'conditions of variance' associated with it.

If that's the case... then riddle me this...

If responses sent from a Content Origin Server ( COS ) that
MAY return compressed ( But there are conditions of
variance known only to the COS ) are going out on the
wire WITHOUT a "Vary:" header ( the uncompressed
variants ).... then how the heck would ANY Proxy Cache
know if/when to send the "compressed" version?

If the uncompressed variant itself is not 'informing' all
Proxy Caches that even though this response happens
to be uncompressed that 'future' requests for this URI
MIGHT be able to be returned compressed... then
that means you aren't getting what you think you
are to your users. 

If the Proxy is not being told to "Vary:" the uncompressed
responses then the uncompressed versions of things
will get STUCK in the Proxy Caches and then
NO ONE will be getting any compressed versions
of the pages.

Now it's mine turn to tell ( someone/anyone ) to tell
me where I am wrong here.

How would any Proxy know to 'check' with a Content
Origin Server to see if the next request for a cached
page should be returned compressed if all it has is
a non-expired non-compressed response in its 
cache and it has NOT been told that it might "Vary:"???

I actually think that Proxy Servers SHOULD simply
be checking for the presence of "Accept-Encoding:"
request headers and 'matching them up' with whatever
it has stored in its cache so it doesn't ever give someone
something they don't want ( or can't handle ) but that's 
outside the HTTP specs and certainly outside the 
scope of this message thread. HTTP is totally dependent on 
this "Vary:" thing and that's all there is to tell any
Proxy what it's supposed to be doing.

Has anyone checked to see if PHP compression and/or
mod_deflate is actually delivering compressed data
when operating through a Proxy Cache? Sounds like they
might START to do so but eventually the uncompressed
variants get STUCK in all the Proxies and now 
NO ONE is actually getting any compressed variants.

Yours...
Kevin

--part1_10e.1b3e139c.2b230aa2_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/7/2002 12:25:16 AM 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">&gt; That was very similar issue with mod_deflate.<BR>
<BR>
I checked the mod_deflate and also the PHP source code and it appears they<BR>
do it the same way -- no Vary header unless sending gzipped content.<BR>
<BR>
So it seems mod_gzip is alone in its sending of Vary headers for both<BR>
gzipped and non-gzipped content?<BR>
<BR>
Jordan Russell<BR>
<BR>
</BLOCKQUOTE><BR>
<BR>
So the assumption that PHP and mod_deflate are assuming<BR>
that the ONLY 'condition of variance' there could ever possibly<BR>
be with regards to delivering compressed/non-compressed<BR>
variants would be the "Accept-Encoding:' field?<BR>
<BR>
That's a pretty dangerous ( and inflexible ) assumption to make.<BR>
<BR>
It also means that if/when PHP/mod_deflate sends a compressed<BR>
response and that ONLY then do they add something like<BR>
"Vary: Accept-Encoding" or "Vary: User-Agent" then the ONLY<BR>
time the Proxy is ever going to check back with the original<BR>
server is if it current has the compressed version in its<BR>
cache ( with the "Vary:" directive associated with it ).<BR>
<BR>
If the last person to ask for the page did NOT have <BR>
"Accept-Encoding:" ( or whatever header it's supposed<BR>
to have according to whatever Vary: was sent )<BR>
then the Cache will now have an 'uncompressed' <BR>
response stored but it will also NOT have any<BR>
'conditions of variance' associated with it.<BR>
<BR>
If that's the case... then riddle me this...<BR>
<BR>
If responses sent from a Content Origin Server ( COS ) that<BR>
MAY return compressed ( But there are conditions of<BR>
variance known only to the COS ) are going out on the<BR>
wire WITHOUT a "Vary:" header ( the uncompressed<BR>
variants ).... then how the heck would ANY Proxy Cache<BR>
know if/when to send the "compressed" version?<BR>
<BR>
If the uncompressed variant itself is not 'informing' all<BR>
Proxy Caches that even though this response happens<BR>
to be uncompressed that 'future' requests for this URI<BR>
MIGHT be able to be returned compressed... then<BR>
that means you aren't getting what you think you<BR>
are to your users. <BR>
<BR>
If the Proxy is not being told to "Vary:" the uncompressed<BR>
responses then the uncompressed versions of things<BR>
will get STUCK in the Proxy Caches and then<BR>
NO ONE will be getting any compressed versions<BR>
of the pages.<BR>
<BR>
Now it's mine turn to tell ( someone/anyone ) to tell<BR>
me where I am wrong here.<BR>
<BR>
How would any Proxy know to 'check' with a Content<BR>
Origin Server to see if the next request for a cached<BR>
page should be returned compressed if all it has is<BR>
a non-expired non-compressed response in its <BR>
cache and it has NOT been told that it might "Vary:"???<BR>
<BR>
I actually think that Proxy Servers SHOULD simply<BR>
be checking for the presence of "Accept-Encoding:"<BR>
request headers and 'matching them up' with whatever<BR>
it has stored in its cache so it doesn't ever give someone<BR>
something they don't want ( or can't handle ) but that's <BR>
outside the HTTP specs and certainly outside the <BR>
scope of this message thread. HTTP is totally dependent on <BR>
this "Vary:" thing and that's all there is to tell any<BR>
Proxy what it's supposed to be doing.<BR>
<BR>
Has anyone checked to see if PHP compression and/or<BR>
mod_deflate is actually delivering compressed data<BR>
when operating through a Proxy Cache? Sounds like they<BR>
might START to do so but eventually the uncompressed<BR>
variants get STUCK in all the Proxies and now <BR>
NO ONE is actually getting any compressed variants.<BR>
<BR>
Yours...<BR>
Kevin<BR>
</FONT></HTML>
--part1_10e.1b3e139c.2b230aa2_boundary--