[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 19:37:23 EST
--part1_1a7.d2e99e8.2b229cc3_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
> robertc@squid-cache.org writes:
>
>> This seems like a significant 'gotcha' to me, as it can defeat the purpose
>> of using gzip compression in the first place. If you have a site with
static
>> pages and a lot of repeat visitors using IE, the total bandwidth consumed
by
>> "mod_gzip + no caching" could end up being higher than "no mod_gzip +
>> caching".
>
> Ouch. And let me say again, Ouch. Vary is core part of HTTP/1.1 design,
> if IE is refusing to cache Vary: objects, it will cause huge issues,
> given the user base. I'd file this as a severe fault with Microsoft
Then send the bug report to SQUID ( squid-cache.org ) as well
SQUID behaves the same way and causes the same problems.
It actually cannot be considered a 'bug', in any event.
There is NO REQUIREMENT for ANY Server to support "Vary:"
in any way, shape or form. It is not a MUST HAVE as far as
HTTP specifications go... it is only labelled as a SHOULD HAVE.
Yours...
Kevin Kiley
In a message dated 12/6/2002 2:20:30 AM Central Standard Time,
robertc@squid-cache.org writes:
> > This seems like a significant 'gotcha' to me, as it can defeat the purpose
> > of using gzip compression in the first place. If you have a site with
> static
> > pages and a lot of repeat visitors using IE, the total bandwidth consumed
> by
> > "mod_gzip + no caching" could end up being higher than "no mod_gzip +
> > caching".
>
> Ouch. And let me say again, Ouch. Vary is core part of HTTP/1.1 design,
> if IE is refusing to cache Vary: objects, it will cause huge issues,
> given the user base. I'd file this as a severe fault with Microsoft - it
> sounds like it is a regression from IE 5.5.
>
>
--part1_1a7.d2e99e8.2b229cc3_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<HTML><FONT FACE=arial,helvetica><FONT SIZE=2><BR>
> robertc@squid-cache.org writes:<BR>
><BR>
>> This seems like a significant 'gotcha' to me, as it can defeat the purpose<BR>
>> of using gzip compression in the first place. If you have a site with static<BR>
>> pages and a lot of repeat visitors using IE, the total bandwidth consumed by<BR>
>> "mod_gzip + no caching" could end up being higher than "no mod_gzip +<BR>
>> caching".<BR>
><BR>
> Ouch. And let me say again, Ouch. Vary is core part of HTTP/1.1 design,<BR>
> if IE is refusing to cache Vary: objects, it will cause huge issues,<BR>
> given the user base. I'd file this as a severe fault with Microsoft<BR>
<BR>
Then send the bug report to SQUID ( squid-cache.org ) as well<BR>
<BR>
SQUID behaves the same way and causes the same problems.<BR>
<BR>
It actually cannot be considered a 'bug', in any event.<BR>
<BR>
There is NO REQUIREMENT for ANY Server to support "Vary:"<BR>
in any way, shape or form. It is not a MUST HAVE as far as<BR>
HTTP specifications go... it is only labelled as a SHOULD HAVE.<BR>
<BR>
Yours...<BR>
Kevin Kiley<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
In a message dated 12/6/2002 2:20:30 AM 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">> This seems like a significant 'gotcha' to me, as it can defeat the purpose<BR>
> of using gzip compression in the first place. If you have a site with static<BR>
> pages and a lot of repeat visitors using IE, the total bandwidth consumed by<BR>
> "mod_gzip + no caching" could end up being higher than "no mod_gzip +<BR>
> caching".<BR>
<BR>
Ouch. And let me say again, Ouch. Vary is core part of HTTP/1.1 design,<BR>
if IE is refusing to cache Vary: objects, it will cause huge issues,<BR>
given the user base. I'd file this as a severe fault with Microsoft - it<BR>
sounds like it is a regression from IE 5.5.<BR>
<BR>
</BLOCKQUOTE><BR>
<BR>
</FONT></HTML>
--part1_1a7.d2e99e8.2b229cc3_boundary--