Just the answer I was looking for. Thanks, Torsten
- Stephen
Torsten Foertsch wrote:
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]
