[Mod_gzip] "mod_gzip_send_vary=Yes" disables caching on IE? (1.3.26.1a)
mod_gzip@lists.over.net
mod_gzip@lists.over.net
Fri, 6 Dec 2002 22:08:06 EST
--part1_12e.1cdc10df.2b22c016_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In a message dated 12/6/2002 7:30:26 PM Central Standard Time,
robertc@squid-cache.org writes:
> On Sat, 2002-12-07 at 12:03, TOKILEY@aol.com wrote:
>
> > Only 3 questions come to mind...
> >
> > 1. Despite what any 'changelog' comment says... how does this
> > REALLY work?
>
> When a response is recieved with Vary, an extra code path is called into
> play.
>
> It does several things:
> 1) Compares the Vary: to the cached object(s) matching the URL. If the
> Vary: is different, they ALL get ejected from the cache.
> 2) It creates a master document in the cache that lists all the
> variations, or obtains that document if it already exists.
> 3) The response is added to the master document.
>
> > 2. Has this version of SQUID been released to the public? Last
> > I heard it has NOT.
>
> Yes, on september 25th. It's squid 2.5 stable 1.
>
> > 3. If it has been released... then how many years will it take before
> > this is still not an issue since there is no assurance that anyone
> > will 'upgrade' their SQUID just because a new version is out.
>
> That is not something we can fix, and is the same as all the other
> broken cache software out there, not just squid < 2.5. However, 2.5 is
> seeing lots of use, with all it's new features.
>
> > Also... SQUID 2.5 still does not have full support for ETag
> > which means, while finally not trashing all "Vary" requests
> > is a step in the right direction ( finally )... it won't mean
> > much until there is full ETag support as well.
> >
> > What's the SQUID timeframe on full ETag support
> > as per HTTP/1.1 specs?
>
> It's slated for 3.something. We're not sure just yet. Apache's ETAG
> support needs serious review first. I did some experimenting, and got
> different ETags for the same object (a .gif from the disk). This will
> actually interact with full ETag support when it happens in squid to
> cause cache misses :[.
>
> There is a DSA development tree that consolidates entities that match on
> MD5 within squid, being done by Yee Man Chan. I think that this may end
> up being the basis for robust ETag support. Just speculation though.
>
> Rob
>
>
Hi Robert...
Thank you again.
That is exactly what I was wondering.
I still don't understand why in the hell SQUID is going to
(as you say) "eject ALL of the cached objects" just
because it gets a "Vary:" on an 'encoding' type. That
simply still violates the "principle of least astonishment"
for me but this is neither the time or the place for that
discussion.
If this discussion goes any farther you will discover that
I personally don't believe that the response encoding
has any business being 'negotiated' with "Vary:" but
for the following 2 reasons it remains the only way
to even TRY and handle the 'problems'.
1. Absolutely NOTHING supports "Transfer-encoding: gzip"
which would be the REAL answer to these issues. Not
even SQUID supports it. An attempt was made once some
years back for SQUID to support it but it was never
finished and no one wants to 'go there' anymore.
2. The HTTP design specs have totally dropped the ball
when it comes to handling response variants that are
NOT based on MIME type, but rather, content encodings.
There just aren't enough options in the protocol to handle
this all correctly and the ones that ARE there ( Vary, Etag,
etc. ) are still bound to cause more problems than they solve.
The only practical advice for folks at this time it to get them
to understand WHY this is all such a mess and let them
make their own intelligent choice(s).
Later...
Kevin
--part1_12e.1cdc10df.2b22c016_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 7:30:26 PM Central Standard Time, robertc@squid-cache.org writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">On Sat, 2002-12-07 at 12:03, TOKILEY@aol.com wrote:<BR>
<BR>
> Only 3 questions come to mind...<BR>
> <BR>
> 1. Despite what any 'changelog' comment says... how does this<BR>
> REALLY work?<BR>
<BR>
When a response is recieved with Vary, an extra code path is called into<BR>
play.<BR>
<BR>
It does several things:<BR>
1) Compares the Vary: to the cached object(s) matching the URL. If the<BR>
Vary: is different, they ALL get ejected from the cache.<BR>
2) It creates a master document in the cache that lists all the<BR>
variations, or obtains that document if it already exists.<BR>
3) The response is added to the master document.<BR>
<BR>
> 2. Has this version of SQUID been released to the public? Last <BR>
> I heard it has NOT.<BR>
<BR>
Yes, on september 25th. It's squid 2.5 stable 1.<BR>
<BR>
> 3. If it has been released... then how many years will it take before<BR>
> this is still not an issue since there is no assurance that anyone<BR>
> will 'upgrade' their SQUID just because a new version is out.<BR>
<BR>
That is not something we can fix, and is the same as all the other<BR>
broken cache software out there, not just squid < 2.5. However, 2.5 is<BR>
seeing lots of use, with all it's new features.<BR>
<BR>
> Also... SQUID 2.5 still does not have full support for ETag<BR>
> which means, while finally not trashing all "Vary" requests<BR>
> is a step in the right direction ( finally )... it won't mean<BR>
> much until there is full ETag support as well.<BR>
> <BR>
> What's the SQUID timeframe on full ETag support<BR>
> as per HTTP/1.1 specs?<BR>
<BR>
It's slated for 3.something. We're not sure just yet. Apache's ETAG<BR>
support needs serious review first. I did some experimenting, and got<BR>
different ETags for the same object (a .gif from the disk). This will<BR>
actually interact with full ETag support when it happens in squid to<BR>
cause cache misses :[.<BR>
<BR>
There is a DSA development tree that consolidates entities that match on<BR>
MD5 within squid, being done by Yee Man Chan. I think that this may end<BR>
up being the basis for robust ETag support. Just speculation though.<BR>
<BR>
Rob<BR>
<BR>
</BLOCKQUOTE><BR>
<BR>
Hi Robert...<BR>
Thank you again.<BR>
<BR>
That is exactly what I was wondering.<BR>
<BR>
I still don't understand why in the hell SQUID is going to<BR>
(as you say) "eject ALL of the cached objects" just <BR>
because it gets a "Vary:" on an 'encoding' type. That<BR>
simply still violates the "principle of least astonishment"<BR>
for me but this is neither the time or the place for that<BR>
discussion. <BR>
<BR>
If this discussion goes any farther you will discover that<BR>
I personally don't believe that the response encoding<BR>
has any business being 'negotiated' with "Vary:" but<BR>
for the following 2 reasons it remains the only way<BR>
to even TRY and handle the 'problems'.<BR>
<BR>
1. Absolutely NOTHING supports "Transfer-encoding: gzip"<BR>
which would be the REAL answer to these issues. Not<BR>
even SQUID supports it. An attempt was made once some<BR>
years back for SQUID to support it but it was never<BR>
finished and no one wants to 'go there' anymore.<BR>
<BR>
2. The HTTP design specs have totally dropped the ball<BR>
when it comes to handling response variants that are<BR>
NOT based on MIME type, but rather, content encodings.<BR>
There just aren't enough options in the protocol to handle<BR>
this all correctly and the ones that ARE there ( Vary, Etag,<BR>
etc. ) are still bound to cause more problems than they solve.<BR>
<BR>
The only practical advice for folks at this time it to get them<BR>
to understand WHY this is all such a mess and let them <BR>
make their own intelligent choice(s).<BR>
<BR>
Later...<BR>
Kevin<BR>
</FONT></HTML>
--part1_12e.1cdc10df.2b22c016_boundary--