Does your handler use Apache::Registry or Apache::PerlRun by any chance?
I did find this code snippet from the ap_add_cgi_vars() within,
the Apache core...
if (r->path_info && r->path_info[0]) {
/*
* To get PATH_TRANSLATED, treat PATH_INFO as a URI path.
* Need to re-escape it for this, since the entire URI was
* un-escaped before we determined where the PATH_INFO began.
*/
request_rec *pa_req;
pa_req = ap_sub_req_lookup_uri(ap_escape_uri(r->pool, r->path_info), r);
....
>From this it seems that, if Apache is asked to setup a CGI environment,
and if path_info is defined, then it will invoke a sub_request.
Quoting giorgos zervas ([EMAIL PROTECTED]):
> Hi,
>
> I followed Lyle's advice and moved my module down to the
> PerlFixupHandler phase and also added the extra logging info.
>
> However I still get, as predicted, one initial request for the correct
> URI and another subrequest for a URI which corresponds to the value I
> set the path_info to. If I don't set the path_info the subrequest
> disappears. So I still wonder why setting the path_info causes a
> subrequest to happen?
>
> Any ideas?
>
> Many thanks,
> Giorgos
>
> Lyle Brooks wrote:
> > Quoting Randy Harmon ([EMAIL PROTECTED]):
> >
> >>I have a similar problem. Yes, I'm getting a subrequest happening. Any
> >>suggestions as to why it's likely to be happening? I'm not explicitly
> >>requesting it.
> >>
> >>In my case, if the requested file is in a directory that didn't exist, this
> >>situation occurs even if I simply return DECLINED; I'd guess the default
> >>handlers are setting path_info, which for some reason is resulting in this
> >>subrequest..
> >>
> >>RAndy
> >
> >
> > This is just a general guess, as depending on your configuration alot of
> > factors (read: modules) could be at work.
> >
> > If I were going to debug it (giorgos's example) further, I'd probably try
> > to do the same operation as a FixupHandler, as opposed to a TransHandler.
> >
> > I say, that because the example was altering only the content generation
> > phase (ie. PerlHander). If moving the code down the request cycle caused
> > the subrequests went away, then you could narrow down what was generating
> > the requestsdown to those modules registered for earlier phases.
> >
> > I also used the term subrequest somewhat "generally", it could be from a
> > a subrequest or an internal redirect. You could insert some code in your
> > handler to clarify it, like this :
> >
> > my $r = shift;
> >
> > my $log = $r->server->log;
> >
> > $r->log->info("\n\nIncoming request");
> > $log->debug("uri = " . $r->uri);
> >
> > $log->debug("initial request - true") if $r->is_initial_req;
> >
> > $log->debug("internal redirect - true")
> > if ($r->is_main and ! $r->is_initial_req);
> >
> > $log->debug("subrequest - true") unless $r->is_main;
> >
> > Then set your LogLevel to "debug" in the httpd.conf file and watch your
> > error_log.
> >
> > HTH
> >
> > Lyle
>
>
>
