Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of info@bnoordhuis.nl designates
 209.85.213.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <AANLkTik0J8k-MF7zUs7-PQ4HhLij=_uqQqgXrqtPVmEp@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>
	<AANLkTinjU6Sx9KGfgEBWMXDN+_pkmKbP4m6bsLhZc4-M@mail.gmail.com>
	<AANLkTiksUEw6SE6aSMJ03NEFT+CNbs6eHQw=0Zdw-CZg@mail.gmail.com>
	<AANLkTik0J8k-MF7zUs7-PQ4HhLij=_uqQqgXrqtPVmEp@mail.gmail.com>
Date: Tue, 4 Jan 2011 00:38:00 +0100
Message-ID: <AANLkTinnMNfAX3yr65OmWeF2+Ffm9-fPVa8U_c2Bm+Hj@mail.gmail.com>
Subject: Re: Overriding mod_rewrite from another module
From: Ben Noordhuis <info@bnoordhuis.nl>
To: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 3, 2011 at 23:19, Joshua Marantz <jmarantz@google.com> wrote:
> My goal is not to remove authentication from the server; only from messin=
g
> with my module's rewritten resource. =A0The above statement is just obser=
ving
> that, while it's possible to shunt off mod_rewrite by returning OK from a=
n
> upstream handler, the same is not true of mod_authz_host because it's
> invoked with a different magic macro.

My bad, I parsed your post as 'mod_authz_host is a core module and
cannot be removed' which is obviously false but not what you meant.

Yes, all auth_checker hooks are run. You can't prevent it but you can
catch the 403 on the rebound and complain loudly in the logs.
Actually, that's a lie. You can prevent it and that might also answer
this next bit...

> There may exist some buffer in Apache that's 8k. =A0But I have traced thr=
ough
> failing requests earlier that were more like 256 bytes. =A0This was repor=
ted
> as mod_pagespeed Issue
> 9<http://code.google.com/p/modpagespeed/issues/detail?id=3D9> and
> resolved by limiting the number of css files that could be combined toget=
her
> so that we did not exceed the pathname limitations. =A0I'm pretty sure it=
 was
> due to some built-in filter or core element in httpd trying to map the UR=
L
> to a filename (which is not necessary as far as mod_pagespeed is concerne=
d)
> and bumping into an OS path limitation (showing up as 403 Forbidden).

This might be the doing of core_map_to_storage(). Never run into it
myself (with URLs up to 4K, anyway) but there you go.

Okay, here is a dirty secret: if you hook map_to_storage and return
DONE, you bypass Apache's authentication stack - and nearly all other
hooks too. Probably an exceedingly bad idea.

You can however use it to prevent core_map_to_storage() from running.
Just return OK and you're set.

> 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. =A0This change is now
> committed to svn trunk (but not released in a formal patch) as
> http://code.google.com/p/modpagespeed/source/detail?r=3D348 .

Sounds fine, that's the kind of stuff request notes are for.