Re: [Question] Handler executing twice!?!

2003-03-31 Thread Vince Veselosky
AHA! That's the culprit! mod_dir implements this at the fix-up stage to 
allow the directive in .htaccess files, hence my confusion. Thank you 
Stas! It all makes sense now.

-Vince

Stas Bekman wrote:

Vince Veselosky wrote:
[...]
The thing that triggered it was the fact that the url was an 
index.pl file. When called as example.com/index.pl, everything 
worked as expected, but when called as example.com/, apache (or 
something) generated a subrequest for index.pl.

NOW my question is, why does apache generate the subrequest *after* 
the HeaderParser phase, causing it to execute twice? This seems like 
a pure URI translation issue, and I would expect it to happen in the 
URI translation phase, *before* the HeaderParser executes at all. I'm 
wondering if this happens in all requests, or if it is related to 
Apache::Registry in the content handler. I didn't take the time to 
track down exactly where the subrequest originates, so I'm not sure 
if it is a mod_perl issue or just an apache issue. I might one day 
build some test cases and figure it out, but not soon. Anyone have 
some insight to add?


Do you have mod_dir (DirectoryIndex) configured? It performs a 
rewrite/sub_request-redirect in the fixup stage.
http://httpd.apache.org/docs/mod/mod_dir.html
__
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com




Re: [Question] Handler executing twice!?!

2003-03-30 Thread Stas Bekman
Vince Veselosky wrote:

[...]

Now here is the thing. The PerlHeaderParserHandler executes TWICE for 
every request. The second time through is apparently a different Apache 
Could it be that something in your code pushes the handler on the stack again?

I'd suggest debugging with Apache::ShowRequest?
http://search.cpan.org/author/DOUGM/Apache-Module-0.11/lib/Apache/ShowRequest.pm
Do tracing:
http://perl.apache.org/docs/1.0/guide/debug.html#Debug_Tracing
Use the 'h' setting
PerlSetEnv MOD_PERL_TRACE h
Try to use $r-get_handlers() and see what you get.

Finally, if nothing helps, go with gdb.

Also what happens if you don't use Apache::Request?

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: [Question] Handler executing twice!?!

2003-03-30 Thread Vince Veselosky
Whew, okay, I have an answer, but I also still have a question. The 
short explanation:

The bug in my code was the fact that I forgot that a request might 
also be a subrequest, so now I check if the request is_initial_req and 
short circuit if not. (And a tiny bug in my trace code caused my debug 
log to report is_initial_req as true all the time. Stupid operator 
precedence bugs!) That solves my immediate problem and gives me 
something to watch for in future.

The thing that triggered it was the fact that the url was an index.pl 
file. When called as example.com/index.pl, everything worked as 
expected, but when called as example.com/, apache (or something) 
generated a subrequest for index.pl.

NOW my question is, why does apache generate the subrequest *after* the 
HeaderParser phase, causing it to execute twice? This seems like a pure 
URI translation issue, and I would expect it to happen in the URI 
translation phase, *before* the HeaderParser executes at all. I'm 
wondering if this happens in all requests, or if it is related to 
Apache::Registry in the content handler. I didn't take the time to track 
down exactly where the subrequest originates, so I'm not sure if it is a 
mod_perl issue or just an apache issue. I might one day build some test 
cases and figure it out, but not soon. Anyone have some insight to add?

Thanks to everyone who sent help and suggestions!
-Vince Veselosky
http://ice.control-escape.com
Vince Veselosky wrote:

Now here is the thing. The PerlHeaderParserHandler executes TWICE for 
every request. The second time through is apparently a different 
Apache object from the first, as when I write to $r-notes, only the 
values from the second execution are visible to the content handler.

Now, if I comment out the PerlHeaderParserHandler line in the conf 
file, the handler never executes at all (which is expected), so it 
isn't getting pushed onto handlers from somewhere else.

Why is this thing running twice, and how can I make it stop??? I hope 
someone can hit me over the head with a clue-stick, because this thing 
is driving me completely bananas!

All help is greatly appreciated,
Vince Veselosky
http://ice.control-escape.com







Re: [Question] Handler executing twice!?!

2003-03-30 Thread Stas Bekman
Vince Veselosky wrote:
[...]
The thing that triggered it was the fact that the url was an index.pl 
file. When called as example.com/index.pl, everything worked as 
expected, but when called as example.com/, apache (or something) 
generated a subrequest for index.pl.

NOW my question is, why does apache generate the subrequest *after* the 
HeaderParser phase, causing it to execute twice? This seems like a pure 
URI translation issue, and I would expect it to happen in the URI 
translation phase, *before* the HeaderParser executes at all. I'm 
wondering if this happens in all requests, or if it is related to 
Apache::Registry in the content handler. I didn't take the time to track 
down exactly where the subrequest originates, so I'm not sure if it is a 
mod_perl issue or just an apache issue. I might one day build some test 
cases and figure it out, but not soon. Anyone have some insight to add?
Do you have mod_dir (DirectoryIndex) configured? It performs a 
rewrite/sub_request-redirect in the fixup stage.
http://httpd.apache.org/docs/mod/mod_dir.html
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com