On Sat 02 Aug 2008, Stephen Howard wrote:
> I'm issuing a lookup_uri request to launch a subrequest. I'm getting
> a 404 on the subrequest when I get a 200 OK response when visiting
> the same uri from a browser. My suspicion is that this uri, which
> uses a PerlInitHandler to transform the incoming url, can't be found
> under the subrequest because the Init handler is not being run during
> the subrequest.
An URI subreq starts with the URI Translation Phase (PerlTransHandler).
A PerlInitHandler is always skipped for subreqs since it is either a
PerlPostReadRequestHandler which comes before the PerlTransHandler or a
PerlHeaderParserHandler which is explicitly skipped for subreqs, see
httpd-2.x.y/server/request.c:ap_process_request_internal():
/* Only on the main request! */
if (r->main == NULL) {
if ((access_status = ap_run_header_parser(r))) {
return access_status;
}
}
A file subreq starts with the PerlMapToStorageHandler and skips the
PerlHeaderParserHandler as shown.
> How many of the Apache request phases are run under a subrequest, and
> if not all, then is there a way to indicate that I want some or all
> of them to run?
Subreqs and internal redirects can skip Access, Authen and Authz. The
initial req runs at least Access but can skip Authen and Authz
depending on Satisfy and whether authentication is required or not.
So the only phases that are really run by all requests are MapToStorage,
TypeChecker and Fixup.
The correct phase to transform the URI is a PerlTransHandler. It is run
for the initial req as well as for URI subreqs but is skipped for file
subreqs that don't have an URI by definition.
Yes, you can change that behavior by patching Apache.
Torsten
--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]
