This sounds scary! How do large companies enable gzip then? How many hoops
do they jump through? sounds like those hoops are in thousands!
And I don't understand how one company's setup would be different from
another still, even if situation is that bad as you describe it.
What kind of trade-offs do large companies go for when they enable gzip?
more overall traffic? no cache?
Sergey
On Tue, Jun 1, 2010 at 6:17 PM, <toki...@aol.com> wrote:
> > There is zero reason for us to avoid putting deflate into the default
> configuration.
>
> Sorry. There ARE (good) reasons to avoid doing so.
>
> I'm the one who wrote the FIRST mod_gzip module for Apache 1.x series
> so you would think I'd be a strong advocate of 'auto-enablement' by
> default,
> but I am NOT. There is HOMEWORK involved here and most users will get
> into deep tapioca unless they understand all the (ongoing) issues.
>
> > it is also very arguable that we should leave it off.
>
> Yes, it is.
>
> > I think others have argued well to enable it by default.
>
> Disagree. I haven't seen the 'good' argument for 'auto-enablement' yet.
>
> Some of the reasons to NOT 'go there' are coming out in other
> similar threads right now...
>
> Here's a clip from the (concurrent) message thread entitled...
>
> 'Canned deflate conf in manual - time to drop the NS4/Vary'
>
> [snip]
>
> 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
>
> [snip]
>
>
>
> -----Original Message-----
> From: Greg Stein <gst...@gmail.com>
> To: dev@httpd.apache.org
> Sent: Tue, Jun 1, 2010 7:40 am
> Subject: Re: Fast by default
>
> Geez, Eric. No wonder people don't want to contribute to httpd, when they
> run into an attitude like yours. That dismissiveness makes me embarressed
> for our community.
> There is zero reason for us to avoid putting deflate into the default
> configuration.
> It is also very arguable that we should leave it off. I think others have
> argued well to enable it by default, while you've simply dismissed them with
> your holier-than-thou attitude and lack of any solid rationale.
> -g
>
> On May 31, 2010 8:06 PM, "Eric Covener" <cove...@gmail.com> wrote:
>
> On Mon, May 31, 2010 at 8:30 PM, Bryan McQuade <bmcqu...@google.com>
> wrote:
> > I propose providing an...
> An additional httpd.conf doesn't sound valuable to me. What slice of
> non-savvy users would scrutinize an alternate config file, can replace
> the config file of their webserver, isn't using a webserver packaged
> by their OS, and wouldn't have just gotten the same information today
> from the manual and 400,000 other websites?
>
> There's currently no <ifModule> bloat in the default conf, but you're
> welcome to submit a patch that adds one for deflate or expires (latter
> seems more unwise to me). See the "supplemental configuration" section
> of the generated config.
>
> This doesn't address mass-vhost companies failing to allow deflate
> because it's not in the no-args HTTPD ./configure , which sounds
> far-fetched to me. I can't recall a users@ or #httpd user implying
> being subjected to such a thing with their own build or with cheap
> hosting.
>
> --
> Eric Covener
> cove...@gmail.com
>
>
