Re: PerlTransHanlder and path_info() question
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
>
>
>
Re: PerlTransHanlder and path_info() question
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
PerlTransHanlder and path_info() question
Hello all,
I have the following question on which I would appreciate any insight.
I have written a failry simple multiplexing PerlTransHandler. Its task
is to check the uri and if it matches a certain string then push an
associated PerlHandler onto the stack. An example can make it clearer:
Let's say I make the following request:
GET /action1/arg1
The PerlTransHandler has a hash, mapping actions to modules like that:
%h = (
'/action1' => My::Module1,
'/action2' => My::Module2,
);
so by checking all the keys of the hash against the uri with a regex it
will eventually match the '/action1' and do the following:
$r->push_handlers(PerlHandler => $h{action1});
More importantly it will also set the path_info to the rest of the uri,
ie /arg1, so that it can later be read by the PerlHandler that was
pushed onto the stack:
$r->path_info('/arg1');
and finally:
return OK;
so that no other PerlTransHandler is invoked.
Up to here everything works fine and eventually the PerlHander
My::Module1 is invoked and the path_info is read correctly.
My problem arose when I added some debugging info to the
PerlTransHandler and I realized that it was actually invoked twice for
each request!
I realized this by tracing the current_callback, URI and path_info in my
error logs. When I did that I got two consecutive entries from the
translation handler:
PerlTransHandler URI=/action1/arg1 path_info=
PerlTransHandler URI=/arg1 path_info=
PerlHandler URI=/action1/arg1 path_info=/arg1
My question is why does the second line appear? I never made an explicit
request for this URI (/arg1).
By doing some extra testing I realized that if I don't set the path_info
in my PerlTransHandler then I avoid the duplication. But I still do not
understand why if I set the path_info so that my PerlHandler can read
its arguments from there I get the duplication effect. My scripts work
perfectly well so this is more of an academic issue but still any help
would be greatly appreciated.
Many thanks,
Giorgos
