help with Apache::DB
hi all, i am using Apache::DB to debug my mod_perl handlers and altough the debugger seems to be working fine it won't display the source code next to the current line being debugged. for example: DB10 r scalar context return from CODE(0x8d7101c): - undef Apache::DB::CODE(0x8d7101c)(/usr/local/lib/perl/5.6.1/Apache/DB.pm:35): 35: next to the line starting with 35: the 35th line of source code should be displayed. however this doesn't happen either with my modules or the ones from CPAN. i even thought it might me a font problem and tried to use different terminals and font combinations but none of them worked for me. has anyone else encountered a similar problem? many thanks, giorgos
help with Apache::DB
hi all, i am using Apache::DB to debug my mod_perl handlers and altough the debugger seems to be working fine it won't display the source code next to the current line being debugged. for example: DB10 r scalar context return from CODE(0x8d7101c): - undef Apache::DB::CODE(0x8d7101c)(/usr/local/lib/perl/5.6.1/Apache/DB.pm:35): 35: next to the line starting with 35: the 35th line of source code should be displayed. however this doesn't happen either with my modules or the ones from CPAN. i even thought it might me a font problem and tried to use different terminals and font combinations but none of them worked for me. has anyone else encountered a similar problem? many thanks, giorgos
Re: $r-path_info() getting confused
hi there, someone asked a similar question a while ago and here the answer that i gave them... i think it answers your question too. START apache uses a simple technique for determining the path_info. it starts at your document root and looks for the directory you specified in your URI. it continues to go deeper in the directory structure until it encounters a directory(or file) that doesn't exist. when this happens the path_info is set to rest of the URI (not including the last part which wasn't found!). so in your case apache looks for $DOCROOT/debug this doesn't exist (presumably) in your $DOCROOT. so the path_info is set to whatever is left, ie nothing! if you tried to request www.host/debug/foo the path_info would be /foo (without the /debug part) if you created a directory called debug inside you docroot and you tried the previous example then you path_info would be empty. i hope this doesn't confuse you a a lot! - END in your example you request /rms/module/foo apache looks for /rms in your docroot and /rms is not found. consequently the path_info is set to the remaining part of the URI, ie /module/foo apache doesn't take into consideration Location directives when setting the path_info as far as i know. best regards, giorgos Fran Fabrizio wrote: In my conf file, I have the following directives: Location /rms AuthType Apache::AuthCookieRMSDBI AuthName RMS PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize require valid-user /Location Location /rms/module SetHandler perl-script PerlHandler RMS::Control::Module-handler /Location When I call the URL /rms/module/foo, and in RMS::Control::Module-handler I examine $r-path_info, I get as a value '/module/foo' rather than the expected '/foo'. If apache recognized that /rms/module/foo was to go to RMS::Control::Module-handler then it knows that /rms/module is the script name and thus should know that path_info should be just /foo, right? Thanks, Fran
Re: path_info() query.
hi, apache uses a simple technique for determining the path_info. it starts at your document root and looks for the directory you specified in your URI. it continues to go deeper in the directory structure until it encounters a directory(or file) that doesn't exist. when this happens the the path_info is set to rest of the URI (not including the last part which wasn't found!). so in your case apache looks for $DOCROOT/debug this doesn't exist (presumably) in your $DOCROOT. so the path_info is set to whatever is left, ie nothing! if you tried to request www.host/debug/foo the path_info would be /foo (without the /debug part) if you created a directory called debug inside you docroot and you tried the previous example then you path_info would be empty. i hope this doesn't confuse you a a lot! best regards, giorgos Wes Cravens wrote: Hello all, This is perhaps an apahce uri translation problem but: I am having a path_info problem... Synopsis. Location / SetHandler perl-script PerlHandler Module /Location Module.pm returns $r-path_info() in html to client. url: 'www.host/' returns '/' url: 'www.host/debug' returns '' when I was expecting '/debug' Now I can get around this with $r-uri but want to make sure that I undestand what I don't understand. Thanks for any help. Wes Rev. FPCED(UK) y n=-09hu6+40563 2136+-*+96, 3.-/n*+963.h
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
