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
Attachment:
signature.asc
Description: OpenPGP digital signature
|