Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of jmarantz@google.com designates
 216.239.44.51 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=google.com; s=beta;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=DImd8MxU1Ci2YlNiLkb4LTHeHdqSjKEM4dcZLhHdnSlTt7h1ykBdhjQihbzXWz454R
         Gm8f06iJUDlx7n+0g94w==
MIME-Version: 1.0
In-Reply-To: <AANLkTi=KPb_PwvTpKAnmW2-eFfXw4xcg8uSPFu9nQQsS@mail.gmail.com>
References: <AANLkTikJBU+kJkU1hCBZAS+9V=t_5e+R6bFjupiumFKt@mail.gmail.com>
 <AANLkTinpeH1hUPB9CvVymeVFBzXqxfzufeHVGTkKS2+h@mail.gmail.com>
 <AANLkTikYBHHBgedoDrec2_Nh8wF6F6wV6+kn4P-XYbYT@mail.gmail.com>
 <AANLkTin54VbAf22rk-aO8Sn=nPLC1Qbqg_JKfe4+Q7qD@mail.gmail.com>
 <AANLkTin+h_PSLKt8fe4h+5aK=h75a=4ue2r2Pez_=suU@mail.gmail.com>
 <AANLkTi=KPb_PwvTpKAnmW2-eFfXw4xcg8uSPFu9nQQsS@mail.gmail.com>
From: Joshua Marantz <jmarantz@google.com>
Date: Mon, 3 Jan 2011 16:07:19 -0500
Message-ID: <AANLkTinjU6Sx9KGfgEBWMXDN+_pkmKbP4m6bsLhZc4-M@mail.gmail.com>
Subject: Re: Overriding mod_rewrite from another module
To: modules-dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=00221532c8f0cfb3370498f78a90

--00221532c8f0cfb3370498f78a90
Content-Type: text/plain; charset=ISO-8859-1

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:

  AP_IMPLEMENT_HOOK_RUN_ALL(int,access_checker,
                          (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.

-Josh

On Mon, Jan 3, 2011 at 1:10 PM, Joshua Marantz <jmarantz@google.com> wrote:

> 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 <jmarantz@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 <info@bnoordhuis.nl> wrote:
>>
>>> On Sat, Jan 1, 2011 at 00:16, Joshua Marantz <jmarantz@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!
>>>
>>
>>
>

--00221532c8f0cfb3370498f78a90--