[users@httpd] problems with delivering precompressed content

[Edgar Frank <ef...@email.de>]

Hi apache folks,

I've been struggling with precompressed content for a while now, but I 
can't find a satisfying solution.

There are plenty of .js and .css, which I currently compress at runtime 
with mod_deflate.

To save CPU load, I want to precompress these, put them as .(js|css).gz 
on the server and deliver the precompressed variant transparently 
depending on Accept-Encoding.

By now, I tried two possible ways of doing this.

1) mod_rewrite
I tried to switch according to RewriteCond's, while checking the 
accessibility of the requested file and the rewritten file with 
subrequests (security concerns). While this seems to work, the security 
guys at my company complain, that mod_rewrite should be absolutely the 
last resort. If mod_rewrite would be the solution, we'd rather do 
dynamic compression (this might sound paranoid, but they have good 
reason and we have a very high focus on security).

2) mod_negotiation
I tried both MultiViews and type-maps. Maybe I misunderstood typemaps - 
but, I would have to place a <filename>.var file everywhere I want a 
negotiated file? This would be cumbersome, as I want the negotiation to 
be transparent and I don't want the user to request a .js.var file.

So I switched to MultiViews, which brings up the next problem. I have to 
rename the uncompressed file to something else like <name>.js.plain for 
MultiViews to kick in on GET /name.js. After removing .gz as a known 
type and adding the encoding to mod_mime, delivery of precompressed 
content works fine.

Unfortunately, the plain content is no longer accessible. The plain file 
isn't a variant for mod_negotiation, if I get it right. I would have to 
associate the identity encoding with a negotiable file extension. But I 
found no way to accomplish this.


So now, I'm looking for other ways. I noticed mod_gzip, which looks like 
it could do this sort of thing. But there were no updates for quite a 
time now and it's not an Apache project, which discourages its use for 
us (security concerns and a different release cycle).

So I'd like to know, what your suggestions are. Is there a way to get 
mod_negotiation to work the way I have in mind? Am I missing something 
or is there an alternative solution?

Regards,
Edgar

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] problems with delivering precompressed content

[Eric Covener <co...@gmail.com>]

> Did you mean rewriting /foo.js to /foo? Sounds interesting, especially
> with the [PT] flag.

yes, had it backwards

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] problems with delivering precompressed content

[Edgar Frank <ef...@email.de>]

Am 20.04.2011 20:25, schrieb Eric Covener:
>> So I'd like to know, what your suggestions are. Is there a way to get
>> mod_negotiation to work the way I have in mind? Am I missing something or is
>> there an alternative solution?
>
> I've never understood this much -- but I thought this worked as long
> as your links were to /foo instead of /foo.js with foo.js and
> foo.js.gz in the filesystem.

This might be a possibility, but I dislike the loss of information.
IMHO it should be clearly visible to the user which type of resource he
requests by the the file extension. But I'll discuss that.

> You could rewrite these on the way in, from /foo to /foo.js with the
> [PT] flag, then let multiviews pick and setup the headers.  Other
> people use rewrite and mod_setenvif/mod_headers all the way through
> and skip mod_negotiation.

Did you mean rewriting /foo.js to /foo? Sounds interesting, especially
with the [PT] flag. This should circumvent the possibility of
parsing the rewritten url as a filesystem path, right?
(e.g. requesting /etc/passwd.js)

> I think there's lot of room for improvement in httpd and in the doc or
> wiki for precompressed content on an existing site.

I'm looking forward to it. Admittedly the docs didn't help me that much
so I dived into the source of mod_negotiation, which is quite a
bunch of code (~3000-4000 lines).

Regards,
Edgar

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] problems with delivering precompressed content

[Eric Covener <co...@gmail.com>]

> So I'd like to know, what your suggestions are. Is there a way to get
> mod_negotiation to work the way I have in mind? Am I missing something or is
> there an alternative solution?

I've never understood this much -- but I thought this worked as long
as your links were to /foo instead of /foo.js with foo.js and
foo.js.gz in the filesystem.

You could rewrite these on the way in, from /foo to /foo.js with the
[PT] flag, then let multiviews pick and setup the headers.  Other
people use rewrite and mod_setenvif/mod_headers all the way through
and skip mod_negotiation.

I think there's lot of room for improvement in httpd and in the doc or
wiki for precompressed content on an existing site.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org