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