httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Re: [PATCH] mod_deflate
Date Sat, 16 Feb 2002 20:14:33 GMT
Justin Erenkrantz wrote:
> On Sat, Feb 16, 2002 at 06:59:40PM +0100, Sander Striker wrote:
>>>Wow!  Obviously the code/default config need to be extremely
>>Yes.  But browsers change (evolve to better things we hope), so config has
>>my preference.  Hardcoding in default rules is badness IMHO.  But maybe that's
>>just me.
> -1 if these restrictions are hardcoded in the module like it was
> before Sander's patch.  These problems should be handled by the
> configuration of mod_deflate not by hardcoding rules.

this is BULLSHIT justin.
you can't veto a change to make it behave like the old (more 
conservative) behavior.
GZIP encoding it VERY badly broken in all of the common browsers
and saying 'well fix the browsers' isn't going to cut it. for a couple 
of reasons
1. apache 2 has 0% market share
2. browsers arent going to get fixed just because we want them to
3. people are still using netscape 3.x out there, people will be using
    these broken browsers for a VERY long time.
4. with sander's 2 patches we are now forcing everybody running a server
    to suffer. I'm still not sure how you will be able to serve normal
    pages on the same server as SVN, without having to resort to some
    kind of trickery. I don't with the current method of browsermatch it
    will work.

I like Igor's approach.
we should be creating a directive/environment variable for SVN's case 
and forcing them to configure it, not the other way around.

> When we added mod_deflate to the tree, we knew that we would have to
> fine tune its configuration syntax to compensate for bad browsers.
> Igor's listing is an invaluable first step.  -- justin
since when.
in the discussions I always said 'text/html' only as browsers were way 
too buggy to handle anything else. I didn't just go add the check 
because it looked nice. most of the RC's 1.3 gzip's problems where due 
to people trying to compress too much and the browsers busting all the 
time. the text/html was a concisous choice only to do a 80/20 rule. 80% 
of the compression savings with 20% of the effort.



View raw message