Adding RemoveOutputFilterByType?

[Justin Erenkrantz <je...@apache.org>]

On Fri, Jul 19, 2002 at 04:24:06PM -0600, Jerry Baker wrote:
> If I exclude IE from it, I just removed 95% of my possible savings 
> because that's what 90% of browsers are using. So, I need to not 
> compress images for IE, but compress all text. Then I need to compress 
> only HTML for NN4, and everything for all other browsers that accept 
> gzip encoding. There is no way to set this up currently.

BTW, a js file maps to application/x-javascript, so restricting to
text/* isn't going to help you much.

Perhaps what we need is to attack this from the opposite angle:
that is, remove DEFLATE when it *is* a certain type.  And, be
able to trigger that with a BrowserMatch directive.  In short
that means we need to add two things: RemoveOutputFilterByType and
have BrowserMatch be able to do that conditionally for certain
browsers.  The first part is fairly easy to add.

The second one goes a bit beyond what BrowserMatch or our current
config framework can do.  But, I think it would be *really* neat
if we could have:

BrowserMatch "MSIE" Does-Not-Support-Image-Deflating
BrowserMatch "NN4" Does-Not-Support-Image-Deflating

<IfEnv Does-Not-Support-Image-Deflating>
  RemoveOutputFilterByType DEFLATE image/*
</IfEnv>

I don't know how to do this, but I think it'd be neat.

I do know that we haven't put much thought into controlling filters.
This is something that really hasn't been addressed yet.  -- justin

Re: Adding RemoveOutputFilterByType?

[Jerry Baker <je...@attbi.com>]

Justin Erenkrantz says:

>On Fri, Jul 19, 2002 at 05:12:42PM -0600, Jerry Baker wrote:
>> Maybe allowing BrowserMatch containers? There seems to be a lot of 
>> things that could be browser dependent, so maybe including it all in a 
>> container would be easier.
>> 
>> <BrowserMatch "Gecko">
>>   SetOutputFilter DEFLATE
>> </BrowserMatch>
>> 
>> <BrowserMatch "MSIE (5|6)">
>>  AddOutputFilter DEFLATE htm html js css
>>  AddOutputFilter INCLUDES;DEFLATE shtm shtml
>> </BrowserMatch>
>
>The only reason I'd separate it out in the way that I did was so
>that separate browsermatches could set a common variable.  Then,
>for each variable, you could set it up so that it executes a
>chunk.  This way achieves the same thing albeit differently.
>
>Either way, this introduces run-time conditional configs.  That's
>new, and I'm not sure if we have the infrastructure to support this.
>But, I'm thinking this will be essential to configuring filters in
>complex situations.  -- justin
>
>  
>
I also tried this:

BrowserMatch "Gecko" gzip_all
SetOutputFilter DEFLATE env=gzip_all

but apparently you can only do that with the CustomLog directive.

So, you are right. There is no way in Apache to configure filters very 
effectively. I hope this gets some attention in the near future. In the 
meantime, I'll just hack mod_deflate for my own purposes.

Thanks.

Re: Adding RemoveOutputFilterByType?

[Justin Erenkrantz <je...@apache.org>]

On Fri, Jul 19, 2002 at 05:12:42PM -0600, Jerry Baker wrote:
> Maybe allowing BrowserMatch containers? There seems to be a lot of 
> things that could be browser dependent, so maybe including it all in a 
> container would be easier.
> 
> <BrowserMatch "Gecko">
>   SetOutputFilter DEFLATE
> </BrowserMatch>
> 
> <BrowserMatch "MSIE (5|6)">
>  AddOutputFilter DEFLATE htm html js css
>  AddOutputFilter INCLUDES;DEFLATE shtm shtml
> </BrowserMatch>

The only reason I'd separate it out in the way that I did was so
that separate browsermatches could set a common variable.  Then,
for each variable, you could set it up so that it executes a
chunk.  This way achieves the same thing albeit differently.

Either way, this introduces run-time conditional configs.  That's
new, and I'm not sure if we have the infrastructure to support this.
But, I'm thinking this will be essential to configuring filters in
complex situations.  -- justin

Re: Adding RemoveOutputFilterByType?

[Jerry Baker <je...@attbi.com>]

Justin Erenkrantz says:

>The tact that we have taken is that mod_deflate shouldn't know
>anything.  It should just compress whatever it gets.  That places
>the burden on the filter configuration system/syntax to allow the
>administrator to place in the overrides.  As you've pointed out,
>it isn't very flexible now.  -- justin
>
>  
>
Maybe allowing BrowserMatch containers? There seems to be a lot of 
things that could be browser dependent, so maybe including it all in a 
container would be easier.

<BrowserMatch "Gecko">
   SetOutputFilter DEFLATE
</BrowserMatch>

<BrowserMatch "MSIE (5|6)">
  AddOutputFilter DEFLATE htm html js css
  AddOutputFilter INCLUDES;DEFLATE shtm shtml
</BrowserMatch>

and so on....

Re: Adding RemoveOutputFilterByType?

[Justin Erenkrantz <je...@apache.org>]

On Fri, Jul 19, 2002 at 04:53:51PM -0600, Jerry Baker wrote:
> some other already compressed media also. Whether mod_deflate should 
> know about this, I'm not sure. If it doesn't, I would like the ability 
> to specify what gets gzipped and what doesn't. I know what is generally 
> a good candidate for compression and what isn't, so if the mod_deflate 
> doesn't know I should be able to "tell" it.

The tact that we have taken is that mod_deflate shouldn't know
anything.  It should just compress whatever it gets.  That places
the burden on the filter configuration system/syntax to allow the
administrator to place in the overrides.  As you've pointed out,
it isn't very flexible now.  -- justin

Re: Adding RemoveOutputFilterByType?

[Jerry Baker <je...@attbi.com>]

Justin Erenkrantz says:

>On Fri, Jul 19, 2002 at 04:24:06PM -0600, Jerry Baker wrote:
>> If I exclude IE from it, I just removed 95% of my possible savings 
>> because that's what 90% of browsers are using. So, I need to not 
>> compress images for IE, but compress all text. Then I need to compress 
>> only HTML for NN4, and everything for all other browsers that accept 
>> gzip encoding. There is no way to set this up currently.
>
>BTW, a js file maps to application/x-javascript, so restricting to
>text/* isn't going to help you much.
>
>Perhaps what we need is to attack this from the opposite angle:
>that is, remove DEFLATE when it *is* a certain type.  And, be
>able to trigger that with a BrowserMatch directive.  In short
>that means we need to add two things: RemoveOutputFilterByType and
>have BrowserMatch be able to do that conditionally for certain
>browsers.  The first part is fairly easy to add.
>
>The second one goes a bit beyond what BrowserMatch or our current
>config framework can do.  But, I think it would be *really* neat
>if we could have:
>
>BrowserMatch "MSIE" Does-Not-Support-Image-Deflating
>BrowserMatch "NN4" Does-Not-Support-Image-Deflating
>  
>
Is there somewhere that has documented the compatibility of browsers 
with gzip encoding? The problem with IE is that it can handle everything 
compressed when it is part of an HTML document. So, if you have an image 
like this:

<html>
<body>
<img src="someimage.jpg">
</body>
</html>

And that image gets compressed, IE has no problems with it. But, if you 
request that image directly (http://www.foo.com/someimage.jpg), then IE 
will not display it.

I think it is kind of a waste of time to try and compress some things 
that can't be compressed much further. GIF and JPG come to mind; MP3 and 
some other already compressed media also. Whether mod_deflate should 
know about this, I'm not sure. If it doesn't, I would like the ability 
to specify what gets gzipped and what doesn't. I know what is generally 
a good candidate for compression and what isn't, so if the mod_deflate 
doesn't know I should be able to "tell" it.