RE: $r-prev is always defined
Hello, Unfortunately, I did suspect the same before and called Index.cgi directly. By calling it directly, $r-log_error($r-prev()-uri()) still perfectly printed one line in error_log. It's rather a very strange behaviour that I hope someone could figure it out. $r-prev() returns a blessed reference while $r-main() returns undef. This violates the logic because if $r-prev() does not return undef, then $r-main() should returns something too as $r is one of the subsequent internal redirects when $r-prev() is defined. The workaround I came up is to test $r-main(). If I have the problem figured out I'll let the list know. Yours, Jindo -Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 9:35 PM To: Jindo Cc: [EMAIL PROTECTED] Subject: Re: $r-prev is always defined Jindo wrote: Hello, According to docs, $r-prev returns undef unless there is an internal redirect. But to my surprises, $r-prev is always defined, severely breaking down the code/flow logic of my scripts. Here is what I have in /Index.cgi (My browser defaults to that page) for debugging $r-log_error($r-prev()-uri()); $r-log_error($r-uri()); I'd suspect that it's probably mod_dir (via DirectoryIndex) that's causing this (since it calls ap_internal_redirect, which sets $r-prev and $r-prev-uri). I also suspect that if you called /Index.cgi directly, you'd get a 500 (and $r-prev would be undef so $r-prev-uri would bomb). HTH --Geoff
$r-prev is always defined
Hello, According to docs, $r-prev returns undef unless there is an internal redirect. But to my surprises, $r-prev is always defined, severely breaking down the code/flow logic of my scripts. Here is what I have in /Index.cgi (My browser defaults to that page) for debugging $r-log_error($r-prev()-uri()); $r-log_error($r-uri()); Log shows: [Sat Sep 7 16:35:27 2002] [error] /Index.cgi [Sat Sep 7 16:35:27 2002] [error] /Index.cgi $r-prev() DID RETURN undef in the past. This problem kicked in after I changed my server environment which now goes: RedHat Linux 7.1 (with custom built kernel 2.4.18 SMP) Perl 5.6.1 Apache 1.3.26 (upgraded from Apache 1.3.24) mod_perl 1.27 (upgraded from mod_perl 1.26) mod_gzip 1.3.19a Has anyone experienced such weird behaviour or is there anything I need to watch out to correct this problem? Yours, Jindo
RE: [PING] Sorry, just testing since 26 hours of no activity on this list.
Hi, So haven't I read anything in the past 24 hrs, which is rather strange to me. I even checked out the online archives to make sure it wasn't the mail server that's eating the incoming mails. So where is everybody? Too busy mod_perling? Jindo -Original Message- From: Rodney Broom [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 5:15 AM To: mod_perl list Subject: [PING] Sorry, just testing since 26 hours of no activity on this list. Hi all, I haven't seen anything on this list for the past 26 hours, so I'm just making sure that I'm still seeing new posts. --- Rodney Broom
EVERYTHING=1
Title: Hi! I've always wondered what the advantage will be if I install mod_perl using EVERYTHING=1. Wouldn't EVERYTHING=1 add to the image size of httpd executable and thus enlarge memory consumption? Also, would EVERYTHING=1 incur runtime performance penalty? I was thinking mod_perl will have to walk through all the enabled handlers if all the hooks/handlers are installed. Cheers, Jindo
Apache::ASP - using Apache::Session
Hi! I recently made a decision to adopt Apache::ASP as the template tool for my site. The only thing I'd like to find out is whether or not Apache::ASP works with Apache::Session. I read from an online article http://perl.apache.org/features/tmpl-cmp.html that Apache::ASP can be hookied up to Apache::Session. However, I just could not find the instruction on how this can and should be done. Am I mistaken or have I missed something in the online docs? Thanks for your input. Cheers, Jindo
