[users@httpd] problems with delivering precompressed content
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-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] problems with delivering precompressed content
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-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] problems with delivering precompressed content
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-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] problems with delivering precompressed content
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-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org