httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [users@httpd] Serving pre-compressed static content using httpd 2.2.x
Date Wed, 28 Mar 2012 21:10:48 GMT

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


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:
> 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

View raw message