[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
Mon, 9 Dec 2002 11:37:16 EST
--part1_14e.1877ea2a.2b2620bc_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
> In a message dated 12/9/2002 3:25:32 AM Central Standard Time,
> robertc@squid-cache.org writes:
>
> Vary: *
> Means that the reponse was calculated on *something* that is not
> represented in the REQUEST headers, and thus MUST BE revalidated EVERY
> time.
>
> Caching is allowed, but only in combination with ETAG validation against
> the origin on every request.
Thanks to Robert for clarifying that.
I guess my interpretation of "Vary: *" was just wishful thinking.
I happen to think it SHOULD behave in the way I described to
cover scenarios where you still want things to be CACHED
and ONLY if ANY request headers are different you want a 'check'
with Origin Server.
If you decide you NEVER want something cached ( in order to force
validations on things outside Vary scope like HTTP level, etc ) there
are lots of OTHER ways to do that so I guess I was assuming
"Vary: *" still just applied to REQUEST header 'differences' only.
However... now I am really confused.
What is the actual point of this thread?
According to the way Robert says "Vary: *" is DESIGNED to
work then anyone who is complaining that ANY cache
( inline proxy or browser ) is NOT storing responses that
contain "Vary: *" just doesn't understand that that is what
is SUPPOSED to happen?
Looks like Slava is saying he's not having any problems at
all and that everything is working fine while (Jordan?) says
that MSIE isn't caching ANY of the non-compressed variants
if they have ANY kind of "Vary:" header.
Can we narrow this down to the specific problem and stop
spinning our wheels?
Is this just an MSIE version specific issue?
What (Exact) versions and build levels of MSIE are
we talking about here and does one really actually
WORK while another does NOT?
Where does Netscape fit into all this?
Anyone seeing Netscape refuse to cache "Vary:" responses
even on the non-compressed variants?
Kevin
> Vary: *
> Means that the reponse was calculated on *something* that is not
> represented in the REQUEST headers, and thus MUST BE revalidated EVERY
> time.
>
> Caching is allowed, but only in combination with ETAG validation against
> the origin on every request.
>
--part1_14e.1877ea2a.2b2620bc_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/9/2002 3:25:32 AM Central Standard Time, <BR>
> robertc@squid-cache.org writes:<BR>
> <BR>
> Vary: * <BR>
> Means that the reponse was calculated on *something* that is not<BR>
> represented in the REQUEST headers, and thus MUST BE revalidated EVERY<BR>
> time. <BR>
><BR>
> Caching is allowed, but only in combination with ETAG validation against<BR>
> the origin on every request.<BR>
<BR>
Thanks to Robert for clarifying that.<BR>
<BR>
I guess my interpretation of "Vary: *" was just wishful thinking.<BR>
I happen to think it SHOULD behave in the way I described to<BR>
cover scenarios where you still want things to be CACHED<BR>
and ONLY if ANY request headers are different you want a 'check'<BR>
with Origin Server.<BR>
<BR>
If you decide you NEVER want something cached ( in order to force <BR>
validations on things outside Vary scope like HTTP level, etc ) there<BR>
are lots of OTHER ways to do that so I guess I was assuming<BR>
"Vary: *" still just applied to REQUEST header 'differences' only.<BR>
<BR>
However... now I am really confused.<BR>
<BR>
What is the actual point of this thread?<BR>
<BR>
According to the way Robert says "Vary: *" is DESIGNED to<BR>
work then anyone who is complaining that ANY cache<BR>
( inline proxy or browser ) is NOT storing responses that<BR>
contain "Vary: *" just doesn't understand that that is what<BR>
is SUPPOSED to happen?<BR>
<BR>
Looks like Slava is saying he's not having any problems at<BR>
all and that everything is working fine while (Jordan?) says<BR>
that MSIE isn't caching ANY of the non-compressed variants <BR>
if they have ANY kind of "Vary:" header.<BR>
<BR>
Can we narrow this down to the specific problem and stop<BR>
spinning our wheels?<BR>
<BR>
Is this just an MSIE version specific issue?<BR>
<BR>
What (Exact) versions and build levels of MSIE are<BR>
we talking about here and does one really actually<BR>
WORK while another does NOT?<BR>
<BR>
Where does Netscape fit into all this?<BR>
<BR>
Anyone seeing Netscape refuse to cache "Vary:" responses<BR>
even on the non-compressed variants?<BR>
<BR>
Kevin<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Vary: * <BR>
Means that the reponse was calculated on *something* that is not<BR>
represented in the REQUEST headers, and thus MUST BE revalidated EVERY<BR>
time. <BR>
<BR>
Caching is allowed, but only in combination with ETAG validation against<BR>
the origin on every request.<BR>
</BLOCKQUOTE><BR>
<BR>
</FONT></HTML>
--part1_14e.1877ea2a.2b2620bc_boundary--