[users@httpd] Serving pre-compressed static content using httpd 2.2.x

[Christopher Schultz <ch...@christopherschultz.net>]

All,

I've been reading a bit lately about serving pre-compressed static
content with httpd, and it looks like I have a few options that have
various pros and cons. I'd like to make sure I have things straight
because my testing so far has left me a bit frazzled.

If I'm wrong about any of the assertions below, please correct me. I'd
definitely like to do this the "right way".

Using mod_negotiation, I can either use MultiViews or use a type-map file.

Using a type-map file has these advantages as I see them:

* I can specify all the combinations for content-negotiation and httpd
doesn't have to sniff the directory to determine what combinations are
possible, supported, etc.

Disadvantages are:
* Client must request the ".var" file (or whatever I want to call it
when using "AddHandler") in order to get the negotiated content.
* Type-map file can't provide any fall-back file for when no acceptable
Accept-* headers match. For instance, if Accept-Encoding is not set, I
can't instruct mod_negotiate to serve an uncompressed file because
there's no way to say "this is the default case if nothing else matches".
* Unless I re-name the original file to be something like my.css and the
replace the original my.css with my type-map, I'll have to change all
the links to that file that I have.
* Therefore, I have to make sure that all .css files in that directory
are really type-maps in disguise.

Using MultiViews is nice because you don't need external configuration
files -- just well-named files in the first place. But...
* I can't have the original file (e.g. my.css) actually on the disk,
else httpd will serve the file directly with no negotiation.
* That means I have to move the original file out of the way
* Like type-map strategy, there's no way to provide a fall-back file
when no negotiation matches.

If I don't use content-negotiation, I can use mod_rewrite to fake it:
it's a lot easier to just look for Accept-Encoding and then do an
internal redirect to a pre-compressed file, especially since there's no
issues with language or other Accept-* headers confusing things.

<Directory "/path/to/css/files"
  Options +SymLinksIfOwnerMatch
  RewriteEngine On
  RewriteCond %{HTTP:Accept-Encoding} gzip
  RewriteRule test.css$ /path/to/css/files/test.css.gz [E=gz:1]
  Header set Content-Encoding gzip env=gz
</Directory>

This is great because the original file can sit there on the disk and I
can provide compressed versions of it to clients who can deal with it.
No changing URIs or anything like that.

Only problem is that setting the Content-Encoding header doesn't appear
to be working. When set unconditionally, it works, but when attempting
to use the "gz" environment variable, Content-Encoding doesn't seem to
be set. Also, the "Vary" header doesn't seem to be automatically set.

(Rainer Jung suggested that this would be automatically done by
mod_rewrite in this post: http://markmail.org/message/bxjpwhcw5eubjw5)

Finally, there is mod_asis. I seem to recall playing-around with a
mod_asis configuration long ago that was mostly working, but I can't
find it anymore... nor can I manage to hunt-down the references I used
at the time to build it. The obvious advantage to using mod_asis would
be that the response doesn't need to be "built" by httpd -- instead,
once the file is chosen (using mod_negotiate IIRC) it's just streamed
from disk (or better yet, OS disk cache). But is mod_negotiate required,
and will I have the same problems described above?

Are there any other techniques that will help me accomplish my goal?
Ideally, I'd have a solution that:

1. Provides pre-compressed content to clients that can handle it (duh)
2. Fall-back to uncompressed content if clients can't handle it
3. Allow me to leave my unmodified files on disk under their "real"
   file names
4. Not burn too much resources in the process: minimize regexp matches,
   minimize directory-lookups, etc.

Any corrections to the above or suggestions would be greatly appreciated.

Thanks,
-chris

Re: [users@httpd] Serving pre-compressed static content using httpd 2.2.x

[Rainer Jung <ra...@kippdata.de>]

Hi Chris,

On 28.03.2012 23:10, Christopher Schultz wrote:
> All,
>
> Replying to see if I can get a response. Anyone?
>
> Thanks,
> -chris
>
> On 3/22/12 3:10 PM, Christopher Schultz wrote:
...

>> If I don't use content-negotiation, I can use mod_rewrite to fake it:
>> it's a lot easier to just look for Accept-Encoding and then do an
>> internal redirect to a pre-compressed file, especially since there's no
>> issues with language or other Accept-* headers confusing things.
>>
>> <Directory "/path/to/css/files"
>>    Options +SymLinksIfOwnerMatch
>>    RewriteEngine On
>>    RewriteCond %{HTTP:Accept-Encoding} gzip
>>    RewriteRule test.css$ /path/to/css/files/test.css.gz [E=gz:1]
>>    Header set Content-Encoding gzip env=gz
>> </Directory>
>>
>> This is great because the original file can sit there on the disk and I
>> can provide compressed versions of it to clients who can deal with it.
>> No changing URIs or anything like that.
>>
>> Only problem is that setting the Content-Encoding header doesn't appear
>> to be working. When set unconditionally, it works, but when attempting
>> to use the "gz" environment variable, Content-Encoding doesn't seem to
>> be set.

I'd start debugging this detail problem. I'm pretty sure I got this 
working at least twice. using Apache 2.2.not_too_old.

So first check, whether the "gz" environment variable is actually set. 
For this add %{gz}e (and %{Content-Encoding}o) to your LogFormat. Also 
add a RewriteLog with a high RewriteLogLevel.

Note that I personally didn't use the rules inside a Directory block. I 
also prefer to add the .gz file suffix in front of the originsal suffix, 
so e.g. .gz.css instead of .css.gz, because that way Apache will 
automatically set the Content-Type header correct using the suffix list 
in the mime types file.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] Serving pre-compressed static content using httpd 2.2.x

[Christopher Schultz <ch...@christopherschultz.net>]

All,

Replying to see if I can get a response. Anyone?

Thanks,
-chris

On 3/22/12 3:10 PM, Christopher Schultz wrote:
> All,
> 
> I've been reading a bit lately about serving pre-compressed static
> content with httpd, and it looks like I have a few options that have
> various pros and cons. I'd like to make sure I have things straight
> because my testing so far has left me a bit frazzled.
> 
> If I'm wrong about any of the assertions below, please correct me. I'd
> definitely like to do this the "right way".
> 
> Using mod_negotiation, I can either use MultiViews or use a type-map file.
> 
> Using a type-map file has these advantages as I see them:
> 
> * I can specify all the combinations for content-negotiation and httpd
> doesn't have to sniff the directory to determine what combinations are
> possible, supported, etc.
> 
> Disadvantages are:
> * Client must request the ".var" file (or whatever I want to call it
> when using "AddHandler") in order to get the negotiated content.
> * Type-map file can't provide any fall-back file for when no acceptable
> Accept-* headers match. For instance, if Accept-Encoding is not set, I
> can't instruct mod_negotiate to serve an uncompressed file because
> there's no way to say "this is the default case if nothing else matches".
> * Unless I re-name the original file to be something like my.css and the
> replace the original my.css with my type-map, I'll have to change all
> the links to that file that I have.
> * Therefore, I have to make sure that all .css files in that directory
> are really type-maps in disguise.
> 
> Using MultiViews is nice because you don't need external configuration
> files -- just well-named files in the first place. But...
> * I can't have the original file (e.g. my.css) actually on the disk,
> else httpd will serve the file directly with no negotiation.
> * That means I have to move the original file out of the way
> * Like type-map strategy, there's no way to provide a fall-back file
> when no negotiation matches.
> 
> If I don't use content-negotiation, I can use mod_rewrite to fake it:
> it's a lot easier to just look for Accept-Encoding and then do an
> internal redirect to a pre-compressed file, especially since there's no
> issues with language or other Accept-* headers confusing things.
> 
> <Directory "/path/to/css/files"
>   Options +SymLinksIfOwnerMatch
>   RewriteEngine On
>   RewriteCond %{HTTP:Accept-Encoding} gzip
>   RewriteRule test.css$ /path/to/css/files/test.css.gz [E=gz:1]
>   Header set Content-Encoding gzip env=gz
> </Directory>
> 
> This is great because the original file can sit there on the disk and I
> can provide compressed versions of it to clients who can deal with it.
> No changing URIs or anything like that.
> 
> Only problem is that setting the Content-Encoding header doesn't appear
> to be working. When set unconditionally, it works, but when attempting
> to use the "gz" environment variable, Content-Encoding doesn't seem to
> be set. Also, the "Vary" header doesn't seem to be automatically set.
> 
> (Rainer Jung suggested that this would be automatically done by
> mod_rewrite in this post: http://markmail.org/message/bxjpwhcw5eubjw5)
> 
> Finally, there is mod_asis. I seem to recall playing-around with a
> mod_asis configuration long ago that was mostly working, but I can't
> find it anymore... nor can I manage to hunt-down the references I used
> at the time to build it. The obvious advantage to using mod_asis would
> be that the response doesn't need to be "built" by httpd -- instead,
> once the file is chosen (using mod_negotiate IIRC) it's just streamed
> from disk (or better yet, OS disk cache). But is mod_negotiate required,
> and will I have the same problems described above?
> 
> Are there any other techniques that will help me accomplish my goal?
> Ideally, I'd have a solution that:
> 
> 1. Provides pre-compressed content to clients that can handle it (duh)
> 2. Fall-back to uncompressed content if clients can't handle it
> 3. Allow me to leave my unmodified files on disk under their "real"
>    file names
> 4. Not burn too much resources in the process: minimize regexp matches,
>    minimize directory-lookups, etc.
> 
> Any corrections to the above or suggestions would be greatly appreciated.
> 
> Thanks,
> -chris