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 21:07:19 GMT
I answered my own question by implementing it and failing.  You can't bypass
mod_authz_host because it gets invoked via the magic macro:

                          (request_rec *r), (r), OK, DECLINED)

This means that returning OK from my handler does not prevent
mod_authz_host's handler from being called.

I came up with a simpler idea that does not require depending on
string-literals in mod_rewrite.c.

I still add a translate_name hook to run prior to mod_rewrite, but I don't
try to prevent mod_rewrite from corrupting my URL. Instead I just squirrel
away the uncorrupted URL in my own entry in request->notes so that I can use
that rather than request->unparsed_uri downstream when processing the
request.  This seems to work well.  The only drawback is if the site admin
adds a mod_rewrite rule that mutates mod_pagespeed's resource name into
something that does not pass authentication, then mod_authz_host will reject
the request before I can process it.  This seems like a reasonable tradeoff
as that configuration would likely be borked in other ways besides
mod_pagespeed resources.

Commentary would be welcome.


On Mon, Jan 3, 2011 at 1:10 PM, Joshua Marantz <> wrote:

> I have implemented Ben's hack in mod_pagespeed in
> .  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 <>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 <> wrote:
>>> On Sat, Jan 1, 2011 at 00:16, Joshua Marantz <>
>>> 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
>>> > 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 search, nor the Apache
>>> > Modules<
>>> >book
>>> > offer much detail.
>>> > 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!

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