On Mon, Jan 3, 2011 at 4:50 PM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> > This means that returning OK from my handler does not prevent > > mod_authz_host's handler from being called. > > You're mistaken, Joshua. The access_checker hook by default is empty. > mod_authz_host is a module and it can be disabled (if you're on a > Debian/Ubuntu system, run `a2dismod authz_host` and reload Apache). > My perspective is that my team has implemented an Apache module that was launched on Nov 3 2010. Since its launch, we've encountered a variety of compatibility reports with other modules, notably mod_rewrite. My goal is not to remove authentication from the server; only from messing with my module's rewritten resource. The above statement is just observing that, while it's possible to shunt off mod_rewrite by returning OK from an upstream handler, the same is not true of mod_authz_host because it's invoked with a different magic macro. With respect to the URL length, I'm fairly sure it's nearly 8K (grep > for HUGE_STRING_LEN in core_filters.c). > There may exist some buffer in Apache that's 8k. But I have traced through failing requests earlier that were more like 256 bytes. This was reported as mod_pagespeed Issue 9<http://code.google.com/p/modpagespeed/issues/detail?id=9> and resolved by limiting the number of css files that could be combined together so that we did not exceed the pathname limitations. I'm pretty sure it was due to some built-in filter or core element in httpd trying to map the URL to a filename (which is not necessary as far as mod_pagespeed is concerned) and bumping into an OS path limitation (showing up as 403 Forbidden). I confess I'm not entirely sure what you are trying to accomplish. > You're serving up custom content and you're afraid mod_rewrite is > going to munch the URL? Or is it more involved than that? > That's exactly right. The simplest example is mod_pagespeed can infinitely extend the cache lifetime of a js file, without compromising the site owner's ability to propagate changes quickly, by putting an md5-hash of the css content into the URL. old: <script src="scripts/hacks.js"></script> new: <script src="scripts/hacks.js*.pagespeed.ce.HASH.js*"></script> If some mod_rewrite rule munges "scripts/hacks.js.ce.pagespeed.HASH.js", then mod_pagespeed will fail to serve it. The issue is most simply stated in a Stack Overflow article: http://stackoverflow.com/questions/4099659/mod-rewrite-mod-pagespeed-rewritecond In this case, the user had hand-entered a mod_rewrite rule that broke mod_pagespeed so it made sense for him to fix it there. However, we have heard reports of other cases where a user installs some content-generation software that generate mod_rewrite rules that break mod_pagespeed. Such users may not even know what mod_rewrite is, so they can't easily work around the broken rules. This issue is reported as mod_pagespeed Issue 63<http://code.google.com/p/modpagespeed/issues/detail?id=63> . Hope this clears things up. I'm still interested in your opinion on my solution where I (inspired by your hack) save the original URL in request->notes and then use *that* in my resource handler in lieu of request->unparsed_uri. This change is now committed to svn trunk (but not released in a formal patch) as http://code.google.com/p/modpagespeed/source/detail?r=348 . -Josh
