Michael Peters wrote:
> Ryan Gies wrote:
>
>> Below is an Apache log snippet which traces the handler phases for two
>> requests:
>>
>> A) /scratch/ does NOT have a directory index
>> B) /scratch/foo/ DOES have a directory index (index.html)
>
> So here is mine (the text for die
CORRECTIONS!
On Wed, 29 Oct 2008 15:30:12 -0700
Ryan wrote:
> I tested a PHP script with a syntax error, and I see exactly what
> you're seeing.
No, my test was not valid. $r->status will be 500 when the PHP script
issues: header('HTTP/1.0 500 Error');
> From Apache2::RequestRec documentation
On Wed, 29 Oct 2008 17:51:54 -0400
Michael wrote:
> So "/foo/" goes through some extra steps (lines 2-7) but after that
> it looks the same as "/foo/index.pl" until you hit the die(). Then
> the status for "/foo/index.pl" goes to 500 while the status for
> "/foo" stays at 200.
I tested a PHP scri
Ryan Gies wrote:
Below is an Apache log snippet which traces the handler phases for two
requests:
A) /scratch/ does NOT have a directory index
B) /scratch/foo/ DOES have a directory index (index.html)
So here is mine (the text for die() is "A horrible, terrible death!")
A) /f
Adam Prime wrote:
You should package that up and put it on CPAN.
Attached is a version that works on mod_perl 1.
--
Michael Peters
Plus Three, LP
package Apache::Trace;
use strict;
use Apache::Log();
use Apache::Constants ':common';
our @Phases = qw(
PerlPostReadRequestHandler
PerlTrans
Ryan Gies wrote:
Not a permanent home, but here is module which will slip in and give
you similar messages.
http://dev.livesite.net/Apache-Trace.pm
just put it in a dirctory named 'Apache2' in your @INC and add:
PerlPostReadRequestHandler Apache2::Trace->http_phases
You should package
On Wed, 29 Oct 2008 16:51:51 -0400
Michael wrote:
> This is probably a really dumb question, but how do you get a log
> like that? I tried setting "LogLevel debug" but no dice.
Not a permanent home, but here is module which will slip in and give
you similar messages.
http://dev.livesite.net/Ap
Ryan Gies wrote:
Below is an Apache log snippet which traces the handler phases for two
requests:
This is probably a really dumb question, but how do you get a log like that? I tried setting
"LogLevel debug" but no dice.
--
Michael Peters
Plus Three, LP
Michael Peters wrote:
No, I just get
URI: /foo/ STATUS: 200
Nothing else. The browser get's a 500 and the access log reports 500,
but the actual request gets a 200.
I even tried it from a log handler just to see if I get the same thing. Does it matter that I'm
using Apache::Registry to pro
On Wed, 29 Oct 2008 16:13:32 -0400
Michael wrote:
> Ok then let's talk about "/foo/" and "/foo/index.pl" so that we're
> not talking about the redirect.
Right on
> if it was subrequests that were the problem I would have expected to
> see more than debug statement in the log since the cleanup ha
Adam Prime wrote:
Just to be clear, when you do this:
GET /foo/
do you get this in the error log?
URI: /foo/index.pl STATUS: 500 (the sub request from Directory Index)
URI: /foo/ STATUS: 200 (the original request)
No, I just get
URI: /foo/ STATUS: 200
Nothing else. The browser get's a 500
Michael Peters wrote:
The client always sees the 500 which is what the access log reports as
well. It's just that in the CleanupHandler it comes back as 200 for
/foo/, but 500 for /foo/index.pl.
Just to be clear, when you do this:
GET /foo/
do you get this in the error log?
URI: /foo/ind
Ryan Gies wrote:
On Wed, 29 Oct 2008 15:29:18 -0400
Michael wrote:
So what's going on here. Shouldn't the 2 requests (/foo
and /foo/index.pl) be treated exactly the same?
/foo is much different than /foo/index.pl because /foo is handled by
mod_dir (http://httpd.apache.org/docs/2.0/mod/mod_dir
Michael Peters wrote:
The client always sees the 500 which is what the access log reports as
well. It's just that in the CleanupHandler it comes back as 200 for
/foo/, but 500 for /foo/index.pl.
That really is strange. Perhaps the status is getting mangled at the
end of the Log phase or some
On Wed, 29 Oct 2008 15:29:18 -0400
Michael wrote:
> So what's going on here. Shouldn't the 2 requests (/foo
> and /foo/index.pl) be treated exactly the same?
/foo is much different than /foo/index.pl because /foo is handled by
mod_dir (http://httpd.apache.org/docs/2.0/mod/mod_dir.html).
First, t
Adam Prime wrote:
Michael Peters wrote:
But when I make the request to just /foo (instead of /foo/index.pl) I
only get this in my error log:
URI: /foo/ STATUS: 200
you've said to /foo, but your error_log is saying /foo/. What's going
on there? mod_dir redirecting a bare directory request?
Michael Peters wrote:
But when I make the request to just /foo (instead of /foo/index.pl) I
only get this in my error log:
URI: /foo/ STATUS: 200
you've said to /foo, but your error_log is saying /foo/. What's going
on there? mod_dir redirecting a bare directory request?
The stranger par
I've been banging my head against on wall on this one and could use a little
help.
Setting the Stage:
I've got an Apache::CleanupHandler that is running for my requests. I've got a file at
DocumentRoot/foo/index.pl and DirectoryIndex index.pl. Now, to test out error handling in my cleanup
hand
Philip M. Gollucci wrote:
Joachim Zobel wrote:
Hi.
If stat returns 777 (octal), protection returns 0x777 (hexadecimal). The
documentaion claiming this as the same value should be fixed.
If you can submit a patch or point to this documentation, I'll be glad
to update that for you.
http://sv
Philip M. Gollucci wrote:
Joachim Zobel wrote:
Hi.
If stat returns 777 (octal), protection returns 0x777 (hexadecimal). The
documentaion claiming this as the same value should be fixed.
If you can submit a patch or point to this documentation, I'll be glad
to update that for you.
I'm guess
I am not that far, yet. I am doing all my development work under Windows
and only for production I will use Linux (or Solaris if it needs bigger
iron).
Something to bear in mind then is that apache on Windows is (usually)
multi-threaded rather than multi-process. So a lot of the discussion in t
I won't try to speak for Michael, but technically that memory does not
become available for reuse by Perl, even if they are lexical variables
and they go out of scope, unless you explicitly undef the variables.
Perl keeps the memory for them allocated as a performance
optimization.
That was the
22 matches
Mail list logo
