You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jerry Baker <je...@attbi.com> on 2002/07/19 21:04:12 UTC
Patch mod_deflate to gzip text/*?
Currently mod_deflate has the option of only operating on HTML files,
but I think it might be useful to be able to tell it to only operate on
any text/* content-types. Would a patch for this behavior be welcomed?
Re: Adding RemoveOutputFilterByType?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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.
Adding RemoveOutputFilterByType?
Posted by 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: Patch mod_deflate to gzip text/*?
Posted by Jerry Baker <je...@attbi.com>.
Justin Erenkrantz says:
>On Fri, Jul 19, 2002 at 04:12:40PM -0600, Jerry Baker wrote:
>> But I only want it to gzip js and css when the browser is IE5+ or Mozilla.
>
>Why? Most browsers support gzip if they are sending it in the
>Accept-Encoding header. BTW, you'd just SetOutputFilter DEFLATE in
>your configuration if you want to encode everything.
>
>You'd only want to work around the broken browsers. In my tests,
>Mozilla can accept any sort of deflated input. I don't use IE and
>I have heard that it is broken in many respects of gzip encoding.
>
>If you restrict deflating only to IE5+ or Mozilla, you're going
>to lock out performance gains when people use other browsers
>(or automated tools or client libraries). -- justin
>
>
>
That's why I don't want to do that.
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.
Re: Patch mod_deflate to gzip text/*?
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 19, 2002 at 04:12:40PM -0600, Jerry Baker wrote:
> But I only want it to gzip js and css when the browser is IE5+ or Mozilla.
Why? Most browsers support gzip if they are sending it in the
Accept-Encoding header. BTW, you'd just SetOutputFilter DEFLATE in
your configuration if you want to encode everything.
You'd only want to work around the broken browsers. In my tests,
Mozilla can accept any sort of deflated input. I don't use IE and
I have heard that it is broken in many respects of gzip encoding.
If you restrict deflating only to IE5+ or Mozilla, you're going
to lock out performance gains when people use other browsers
(or automated tools or client libraries). -- justin
Re: Patch mod_deflate to gzip text/*?
Posted by Jerry Baker <je...@attbi.com>.
Justin Erenkrantz says:
>On Fri, Jul 19, 2002 at 03:58:45PM -0600, Jerry Baker wrote:
>> I want it to not compress anything except for text/*. The problem is
>> that IE cannot understand compressed images when the images are not part
>> of an HTML document. So, I want the benefit of compressing js and css
>> files, but do not want to compress images or other binary content.
>
>I think the proper solution is to allow wildcard support in
>AddOutputFiltersByType, so that you can do:
>
>AddOutputFiltersByType DEFLATE text/*
>
>Another solution is to do (can do with the current code):
>
>AddOutputFiltersByType DEFLATE text/html
>AddOutputFilters DEFLATE js css
>
>The addition of wildcard support could get very expensive at
>first thought. Perhaps we could find a way to make that
>efficient. That's unlikely if we keep using a hashtable for
>this. -- justin
>
>
>
But I only want it to gzip js and css when the browser is IE5+ or Mozilla.
Re: Patch mod_deflate to gzip text/*?
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 19, 2002 at 03:58:45PM -0600, Jerry Baker wrote:
> I want it to not compress anything except for text/*. The problem is
> that IE cannot understand compressed images when the images are not part
> of an HTML document. So, I want the benefit of compressing js and css
> files, but do not want to compress images or other binary content.
I think the proper solution is to allow wildcard support in
AddOutputFiltersByType, so that you can do:
AddOutputFiltersByType DEFLATE text/*
Another solution is to do (can do with the current code):
AddOutputFiltersByType DEFLATE text/html
AddOutputFilters DEFLATE js css
The addition of wildcard support could get very expensive at
first thought. Perhaps we could find a way to make that
efficient. That's unlikely if we keep using a hashtable for
this. -- justin
Re: Patch mod_deflate to gzip text/*?
Posted by Jerry Baker <je...@attbi.com>.
Justin Erenkrantz says:
>On Fri, Jul 19, 2002 at 01:04:12PM -0600, Jerry Baker wrote:
>> Currently mod_deflate has the option of only operating on HTML files,
>> but I think it might be useful to be able to tell it to only operate on
>> any text/* content-types. Would a patch for this behavior be welcomed?
>
>Perhaps you are looking at an older version, but the current version
>in CVS will deflate anything you tell it to.
>
>A BrowserMatch that sets "gzip-only-text/html" would enforce that for
>broken browsers that can not accept compressed output for anything
>other than text/html. -- justin
>
>
>
I want it to not compress anything except for text/*. The problem is
that IE cannot understand compressed images when the images are not part
of an HTML document. So, I want the benefit of compressing js and css
files, but do not want to compress images or other binary content.
Re: Patch mod_deflate to gzip text/*?
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 19, 2002 at 01:04:12PM -0600, Jerry Baker wrote:
> Currently mod_deflate has the option of only operating on HTML files,
> but I think it might be useful to be able to tell it to only operate on
> any text/* content-types. Would a patch for this behavior be welcomed?
Perhaps you are looking at an older version, but the current version
in CVS will deflate anything you tell it to.
A BrowserMatch that sets "gzip-only-text/html" would enforce that for
broken browsers that can not accept compressed output for anything
other than text/html. -- justin