Not really - I just know that they serve many users and just wonder how it's
done and why that knowledge is not public.
Just to give you a perspective on decision making in large companies - if
you ordered a work from creative agency, they probably asked you for a list
of supported browsers. Guess how long is the list...
There is always a trade-off in some way or another - I tried to use the web
on Wii and on iPad and the web world looks quite differently there. I'm not
saying that this is the degree most popular web server should go for, just
an illustration.
Sergey
On Tue, Jun 1, 2010 at 10:04 PM, HyperHacker <hyperhac...@gmail.com> wrote:
> On Tue, Jun 1, 2010 at 16:25, Sergey Chernyshev
> <sergey.chernys...@gmail.com> wrote:
> > 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
> >
>
> You seem to think large corporations are competent at web
> design/administration.
>
> --
> Sent from my toaster.
>
