httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <>
Subject Re: Overriding mod_rewrite from another module
Date Mon, 03 Jan 2011 22:19:31 GMT
On Mon, Jan 3, 2011 at 4:50 PM, Ben Noordhuis <> 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<> 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:

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<>

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 .


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message