That's new to me that browsers don't cache stuff that has Vary only on
Accept-Encoding - can you post some statistics or describe the test you ran?
As for *all* content types, I don't think we're talking about compressing
images and it's relatively easy to create a white-list to have gzip on for
by default.
The question regarding support in browsers actually is very serious too and
I'd love to see statistics for that too - it sounds too scary and
middle-ages to me.
I didn't get this impression from all the talks about gzip and research that
guys from Google did, for example, when they were looking for a source of
lower gzip rates (it turned out to be antivirus software stripping
Accept-encoding headers).
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
On Tue, Jun 1, 2010 at 5:44 PM, <toki...@aol.com> wrote:
> Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding'
> then almost ALL browsers will then refuse to cache a response entity
> LOCALLY
> and the pain factor moves directly to the Proxy/Content Server(s).
>
> If you vary on 'User-Agent' ( No longer reasonable because of the abuse
> of that header 'out there'? ) then the browsers WILL cache responses
> locally and the pain is reduced at the Proxy/Content server level, but
> pie is not free at a truck stop and there are then OTHER issues to deal
> with.
>
> The OTHER 'ongoing issue' regarding compression is that, to this day,
> it still ONLY works for a limited set of MIME types. The 'Accept-Encoding:
> gzip,deflate'
> header coming from ALL major browser is still mostly a LIE. It would seem
> to indicate that the MIME type doesn't matter and it will 'decode' for ANY
> MIME type but nothing could be further from the truth. There is no browser
> on the
> planet that will 'Accept-Encoding' for ANY/ALL mime type(s).
>
> If you are going to turn compression ON by default, without the user having
> to
> make any decisions for their particular environment, then part of the
> decision
> for the default config has to be 'Which MIME types?' text/plain and/or
> text/html only? SOME browsers can 'Accept-Encoding' on the ever-increasing
> .js Javascript backloads but some CANNOT.
>
> These 2 issues alone are probably enough to justify keeping compression
> OFF by default. A lot of people that use Apache won't even be able to get
> their heads around either one of these 'issues' and they really SHOULD
> do a little homework before turning it ON.
>
> Someone already quoted that...
>
> 'people expect the default config to just WORK without major issues'.
>
> That's exactly what you have now.
> It's not 'broken'.
> Why change it?
>
> Kevin Kiley
>
>
> -----Original Message-----
> From: Sergey Chernyshev <sergey.chernys...@gmail.com>
> To: dev@httpd.apache.org
> Sent: Tue, Jun 1, 2010 3:09 pm
> Subject: Re: canned deflate conf in manual -- time to drop the NS4/vary?
>
> Yeah, it should only Vary on Accept-encoding (already does). It's still
> not perfect, but at least it doesn't blow up proxies too much.
>
> The question to people with statistics - are there any other issues with
> gzip/proxy configurations?
>
> Sergey
>
>
> On Tue, Jun 1, 2010 at 11:01 AM, Eric Covener <cove...@gmail.com> wrote:
>
>> IIUC, the vary: user-agent to accomodate Netscape 4 is a pain for
>> caches because obviously they can only vary on the entire user-agent.
>>
>> http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
>>
>> Is it time to move this aspect of the snippet into a separate note or
>> some historical trivia section, to remove the Vary?
>>
>> --
>>
>> On the same topic, are there still non-academic CSS and JS compression
>> issues (e.g. XP-era browsers, earlier, later, ???) Should we instead
>> account for these in the "complicated/more compression" example, and
>> is there a way to do so without adding the Vary right back in?
>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>>
>
>
