I have implemented Ben's hack in mod_pagespeed in http://code.google.com/p/modpagespeed/source/detail?r=345 . It works great. But I am concerned that a subtle change to mod_rewrite.c will break this hack silently. We would catch it in our regression tests, but the large number of Apache users that have downloaded mod_pagespeed do not generally run our regression tests.
I have another idea for a solution that I'd like to see opinions on. Looking at Nick Kew's book, it seems like I could set request->filename to whatever I wanted, return OK, but then also shunt off access_checker for my rewritten resources. The access checking on mod_pagespeed resources is redundant, because the resource will either be served from cache (in which case it had to be authenticated to get into the cache in the first place) or will be decoded and the original resource(s) fetched from the same server with full authentication. I'd appreciate any comments on this approach. -Josh On Mon, Jan 3, 2011 at 11:40 AM, Joshua Marantz <jmara...@google.com> wrote: > OK I tried to find a more robust alternative but could not. I was thinking > I could duplicate whatever mod_rewrite was doing to set the request filename > that appears to be complex and probably no less brittle. > > I have another query on this. In reality we do *not* want our rewritten > resources to be associated with a filename at all. Apache should never look > for such things in the file system under ../htdocs -- they will not be > there. We also do not need it to validate or authenticate on these static > resources. > > In particular, we have found that there is some path through Apache that > imposes what looks like a file-system-based limitation on URL segments (e.g. > around 256 bytes). This limitation is inconvenient and, as far as I can > tell, superfluous. URL limits imposed by proxies and browsers are more like > 2k bytes, which would allow us to encode more metadata in URLs (e.g. > sprites). Is there some magic setting we could put into the request > structure to tell Apache not to interpret the request as being mapped from a > file, but just to pass it through to our handler? > > Thanks! > -Josh > > On Sat, Jan 1, 2011 at 6:24 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote: > >> On Sat, Jan 1, 2011 at 00:16, Joshua Marantz <jmara...@google.com> wrote: >> > Thanks for the quick response and the promising idea for a hack. >> Looking at >> > mod_rewrite.c this does indeed look a lot more surgical, if, perhaps, >> > fragile, as mod_rewrite.c doesn't expose that string-constant in any >> formal >> > interface (even as a #define in a .h). Nevertheless the solution is >> > easy-to-implement and easy-to-test, so...thanks! >> >> You're welcome, Joshua. :) >> >> You could try persuading a core committer to add this as a >> (semi-)official extension. Nick Kew reads this list, Paul Querna often >> idles in #node.js at freenode.net. >> >> > I'm also still wondering if there's a good source of official >> documentation >> > for the detailed semantics of interfaces like ap_hook_translate_name. >> > Neither a Google Search, a stackoverflow.com search, nor the Apache >> > Modules< >> http://www.amazon.com/Apache-Modules-Book-Application-Development/dp/0132409674/ref=sr_1_1?ie=UTF8&qid=1293837117&sr=8-1 >> >book >> > offer much detail. >> > code.google.com fares a little better but just points to 4 existing >> usages. >> >> This question comes up often. In my experience the online >> documentation is almost always outdated, incomplete or outright wrong. >> I don't bother looking things up, I go straight to the source. >> >> It's a kind of job security, I suppose. There are only a handful of >> people that truly and deeply understand Apache. We can ask any hourly >> rate we want! >> > >
