$r->status no correct

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
handler I've put an explicit "die" at the top of foo/index.pl.

Problem:
When I make a request to /foo/index.pl every behaves correctly. I get this in my access log:
127.0.0.1 - - [29/Oct/2008:15:19:33 -0400] "GET /foo/ HTTP/1.1" 500 644 "-" "Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.9.0.2) Gecko/2008092318 Fedora/3.0.2-1.fc9 Firefox/3.0.2"

And this in my error log (where I'm printing $r->uri and $r->status from inside the cleanup handler):
URI: /foo/index.pl STATUS: 500

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

The stranger part is that the access log still reports it correctly as an error:
GET /foo/ HTTP/1.1" 500

And the error still appears in the error log, it's just that $r->status (and
$r->notes('error-notes') don't contain the right information).

So what's going on here. Shouldn't the 2 requests (/foo and /foo/index.pl) be treated exactly the same?

--
Michael Peters
Plus Three, LP

Re: $r->status no correct

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 part is that the access log still reports it correctly as
> an error:
> GET /foo/ HTTP/1.1" 500
>
> And the error still appears in the error log, it's just that
> $r->status (and $r->notes('error-notes') don't contain the right
> information).
>
> So what's going on here. Shouldn't the 2 requests (/foo and
> /foo/index.pl) be treated exactly the same?
>
Is this happening with just a mod_perl enabled server, and no proxies or
anything? I don't really know how directory index works, but i'm pretty
sure that what it issues internal redirects (or lookup_uri's) for all
the filenames you've got in your DirectoryIndex config. Is that
behavoir what you're expecting (if not, might it be involved in this odd
behavoir?). Does the client see the 200, or the 500?

Adam

Re: $r->status no correct

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?

Sorry about that. Seems we have a redirect for /foo to /foo/, but the problem still remains if I do
a request for /foo/ direct (no involving the rewrite).

> Is this happening with just a mod_perl enabled server, and no proxies or
> anything?

Yes, I'm making requests directly against the mod_perl server not the proxy. I even tried to see if
maybe $r->is_main changed for those 2 requests, but they are exactly the same.

> Does the client see the 200, or the 500?

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.


--
Michael Peters
Plus Three, LP

Re: $r->status no correct

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, the client must submit the request with a trailing slash, as in
'/foo/'. This is done by returning a 301 redirect (mod_dir). Then, the
redirected (canonical) request comes in and mod_dir starts looking
for your directory index file. Each potential index file is probed via
an Apache sub-request. Your cleanup handler will get called for each
of these sub-requests, and then again on the initial request. You may
find everything is "logical" if you put this at the top of your cleanup
handler:

return Apache2::Const::OK unless $r->is_initial_req;

Re: $r->status no correct

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 something? Maybe it has something to do with
the fact that the Cleanup phase isn't actually an apache phase? What
happens if you try to run your code as a LogHandler instead of a
CleanupHandler?

Adam

Re: $r->status no correct

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.html).

Ok then let's talk about "/foo/" and "/foo/index.pl" so that we're not talking about the redirect.

> return Apache2::Const::OK unless $r->is_initial_req;

I'm now have the following for debugging:
warn "URI: " . $r->uri . " STATUS: " . $r->status
. " main: " . $r->is_main . " initial: " . $r->is_initial_req . "\n";

When run for /foo/index I get:
URI: /foo/index.pl STATUS: 500 main: 1 initial: 1
When run for /foo/ I get:
URI: /foo/ STATUS: 200 main: 1 initial: 1

So they both show up as initial requests and the main request. Plus if it was subrequests that were
the problem I would have expected to see more than debug statement in the log since the cleanup
handler was getting more than once, right?

--
Michael Peters
Plus Three, LP

Re: $r->status no correct

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/index.pl STATUS: 500 (the sub request from Directory Index)
URI: /foo/ STATUS: 200 (the original request)

If that's the case, then the 200 is a bit weird, because it's not
consistent with the actual status returned by the request (which would
be the status of the subrequest), but might be understandable because
the request for /foo/ itself didn't 500. In which case it might
actually be a bug either in Apache, or in mod_perl (i have no idea)

Adam

Re: $r->status no correct

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 and the access log reports 500, but the actual request gets a 200.

--
Michael Peters
Plus Three, LP

Re: $r->status no correct

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 process index.pl?

--
Michael Peters
Plus Three, LP

Re: $r->status no correct

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 handler
> was getting more than once, right?

Yes, absolutely. I think it will come down to how "/foo/index.pl" is
executed. If there is a response handler involved, it must explicitly
set $r->status, simply returning the status is not enough.


....FYI...

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)

Log format is:

[debug] [PID:milliseconds] $r->uri

(A)

[debug] [2828:0.0004] /scratch/
[debug] [2828:0.0004] /scratch/
[debug] [2828:0.0012] /scratch/
[debug] [2828:0.0035] /scratch/
[debug] [2828:0.0038] /scratch/
[debug] [2828:0.0042] /scratch/index.php
[debug] [2828:0.0042] /scratch/index.php
[debug] [2828:0.0050] /scratch/index.php
[debug] [2828:0.0051] /scratch/index.html
[debug] [2828:0.0051] /scratch/index.html
[debug] [2828:0.0052] /scratch/index.html
[debug] [2828:0.0053] /scratch/index.html.var
[debug] [2828:0.0053] /scratch/index.html.var
[debug] [2828:0.0054] /scratch/index.html.var
[debug] [2828:0.0055] /scratch/index.htm
[debug] [2828:0.0055] /scratch/index.htm
[debug] [2828:0.0056] /scratch/index.htm
[debug] [2828:0.0057] /scratch/index.html
[debug] [2828:0.0057] /scratch/index.html
[debug] [2828:0.0058] /scratch/index.html
[error] /var/www/vhosts/mybox.com/htdocs/scratch
[debug] [2828:0.0060] /scratch/
GET 403 /scratch/

(B)

[debug] [2832:0.0004] /scratch/hub/
[debug] [2832:0.0004] /scratch/hub/
[debug] [2832:0.0016] /scratch/hub/
[debug] [2832:0.0040] /scratch/hub/
[debug] [2832:0.0045] /scratch/hub/
[debug] [2832:0.0049] /scratch/hub/index.php
[debug] [2832:0.0049] /scratch/hub/index.php
[debug] [2832:0.0059] /scratch/hub/index.php
[debug] [2832:0.0060] /scratch/hub/index.html
[debug] [2832:0.0060] /scratch/hub/index.html
[debug] [2832:0.0071] /scratch/hub/index.html
[debug] [2832:0.0072] /scratch/hub/index.html
[debug] [2832:0.0084] /scratch/hub/index.html
[debug] [2832:0.0490] /scratch/hub/index.html
[debug] [2832:0.0490] /scratch/hub/index.html
GET 200 /scratch/hub/index.html

Re: $r->status no correct

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

Re: $r->status no correct

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/Apache-Trace.pm

just put it in a dirctory named 'Apache2' in your @INC and add:

PerlPostReadRequestHandler Apache2::Trace->http_phases

Re: $r->status no correct

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 that up and put it on CPAN.

Re: $r->status no correct

This is a multi-part message in MIME format.
--------------020602020103040008070301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------020602020103040008070301
Content-Type: text/plain;
name="Trace.pm"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Trace.pm"

cGFja2FnZSBBcGFjaGU6OlRyYWNlOwp1c2Ugc3RyaWN0Owp1c2UgQXBhY2hl OjpMb2coKTsK
dXNlIEFwYWNoZTo6Q29uc3RhbnRzICc6Y29tbW9uJzsKCm91ciBAUGhhc2Vz ID0gcXcoCiAg
UGVybFBvc3RSZWFkUmVxdWVzdEhhbmRsZXIKICBQZXJsVHJhbnNIYW5kbGVy CiAgUGVybE1h
cFRvU3RvcmFnZUhhbmRsZXIKICBQZXJsSGVhZGVyUGFyc2VySGFuZGxlcgog IFBlcmxBY2Nl
c3NIYW5kbGVyCiAgUGVybEF1dGhlbkhhbmRsZXIKICBQZXJsQXV0aHpIYW5k bGVyCiAgUGVy
bFR5cGVIYW5kbGVyCiAgUGVybEZpeHVwSGFuZGxlcgogIFBlcmxSZXNwb25z ZUhhbmRsZXIK
ICBQZXJsTG9nSGFuZGxlcgogIFBlcmxDbGVhbnVwSGFuZGxlcgopOwoKc3Vi IGhhbmRsZXIo
JCQpIHsKICBteSAoJHBrZ19uYW1lLCAkcikgPSBAXzsKICBfYWRkX2h0dHBf cGhhc2VfdHJh
Y2Vycygkcik7CiAgREVDTElORUQ7Cn0KCnN1YiBfYWRkX2h0dHBfcGhhc2Vf dHJhY2VycyB7
CiAgbXkgJHIgPSBzaGlmdDsKICBmb3IgKEBQaGFzZXMpIHsKICAgIG15ICRw aGFzZV9uYW1l
ID0gJF87CiAgICAkci0+cHVzaF9oYW5kbGVycygkXywgc3ViKCQpIHsKICAg ICAgbXkgJHIg
PSBzaGlmdDsKICAgICAgbXkgJHMgPSAkci0+c2VydmVyOwogICAgICAkcy0+ d2FybihzcHJp
bnRmKCdwaGFzZT0lcywgc3RhdHVzPSVzLCB1cmk9JXMsIGZpbGVuYW1lPSVz JywKICAgICAg
ICAkcGhhc2VfbmFtZSwKICAgICAgICAkci0+c3RhdHVzLAogICAgICAgICRy LT51cmksCiAg
ICAgICAgJHItPmZpbGVuYW1lLAogICAgICApKTsKICAgICAgcmV0dXJuIERF Q0xJTkVEOwog
ICAgfSk7CiAgfQp9CgoxOwoKX19FTkRfXwoKPXBvZDpzdW1tYXJ5IFRyYWNl IG1vZF9wZXJs
IHNlcnZlciBldmVudHMKCj1wb2Q6c3lub3BzaXMKCkluIHlvdXIgQXBhY2hl IGNvbmZpZ3Vy
YXRpb24gZmlsZToKCiAgUGVybFBvc3RSZWFkUmVxdWVzdEhhbmRsZXIgQXBh Y2hlMjo6VHJh
Y2UtPmh0dHBfcGhhc2VzCgpXaWxsIHByb2R1Y2Ugb3V0cHV0IChDPGVycm9y X2xvZz4pIGZv
ciBlYWNoIGh0dHAgcmVxdWVzdCwgZS5nLjoKCiAgLi4uIFt3YXJuXSBwaGFz ZT1QZXJsUG9z
dFJlYWRSZXF1ZXN0SGFuZGxlciwgc3RhdHVzPTIwMCwgdXJpPS8sIGZpbGVu YW1lPQogIC4u
LiBbd2Fybl0gcGhhc2U9UGVybFRyYW5zSGFuZGxlciwgc3RhdHVzPTIwMCwg dXJpPS8sIGZp
bGVuYW1lPQogIC4uLiBbd2Fybl0gcGhhc2U9UGVybE1hcFRvU3RvcmFnZUhh bmRsZXIsIHN0
YXR1cz0yMDAsIHVyaT0vLCBmaWxlbmFtZT0vdmFyL3d3dy92aG9zdHMvZXhh bXBsZS5jb20v
aHRkb2NzLwogIC4uLiBbd2Fybl0gcGhhc2U9UGVybEhlYWRlclBhcnNlckhh bmRsZXIsIHN0
YXR1cz0yMDAsIHVyaT0vLCBmaWxlbmFtZT0vdmFyL3d3dy92aG9zdHMvZXhh bXBsZS5jb20v
aHRkb2NzLwogIC4uLiBbd2Fybl0gcGhhc2U9UGVybEFjY2Vzc0hhbmRsZXIs IHN0YXR1cz0y
MDAsIHVyaT0vLCBmaWxlbmFtZT0vdmFyL3d3dy92aG9zdHMvZXhhbXBsZS5j b20vaHRkb2Nz
LwogIC4uLiBbd2Fybl0gcGhhc2U9UGVybFR5cGVIYW5kbGVyLCBzdGF0dXM9 MjAwLCB1cmk9
LywgZmlsZW5hbWU9L3Zhci93d3cvdmhvc3RzL2V4YW1wbGUuY29tL2h0ZG9j cy8KICAuLi4g
W3dhcm5dIHBoYXNlPVBlcmxGaXh1cEhhbmRsZXIsIHN0YXR1cz0yMDAsIHVy aT0vLCBmaWxl
bmFtZT0vdmFyL3d3dy92aG9zdHMvZXhhbXBsZS5jb20vaHRkb2NzLwogIC4u LiBbd2Fybl0g
cGhhc2U9UGVybExvZ0hhbmRsZXIsIHN0YXR1cz0zMDQsIHVyaT0vaW5kZXgu aHRtbCwgZmls
ZW5hbWU9L3Zhci93d3cvdmhvc3RzL2V4YW1wbGUuY29tL2h0ZG9jcy9pbmRl eC5odG1sCiAg
Li4uIFt3YXJuXSBwaGFzZT1QZXJsQ2xlYW51cEhhbmRsZXIsIHN0YXR1cz0z MDQsIHVyaT0v
aW5kZXguaHRtbCwgZmlsZW5hbWU9L3Zhci93d3cvdmhvc3RzL2V4YW1wbGUu Y29tL2h0ZG9j
cy9pbmRleC5odG1sCgo9Y3V0Cg==
--------------020602020103040008070301--

Re: $r->status no correct

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) /foo/index.pl
B) /foo/

A
====================================================
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlPostReadRequestHandler,
status=200, uri=/foo/index.pl, filename=
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlTransHandler, status=200,
uri=/foo/index.pl, filename=
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlHeaderParserHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlAccessHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlTypeHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlFixupHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:06 2008] [error] A horrible, terrible death!

[Wed Oct 29 17:46:06 2008] [warn] phase=PerlLogHandler, status=500,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
CLEAN URI: /foo/index.pl STATUS: 500 main: 1 initial: 1
[Wed Oct 29 17:46:06 2008] [warn] phase=PerlCleanupHandler, status=500,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl


B
====================================================
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlPostReadRequestHandler,
status=200, uri=/foo/, filename=
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlTransHandler, status=200,
uri=/foo/, filename=
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlHeaderParserHandler, status=200,
uri=/foo/, filename=/tmp/test_client_pub/foo
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlAccessHandler, status=200,
uri=/foo/, filename=/tmp/test_client_pub/foo
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlTypeHandler, status=200,
uri=/foo/, filename=/tmp/test_client_pub/foo
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlFixupHandler, status=200,
uri=/foo/, filename=/tmp/test_client_pub/foo
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlPostReadRequestHandler,
status=200, uri=/foo/index.pl, filename=
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlTransHandler, status=200,
uri=/foo/index.pl, filename=
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlHeaderParserHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlAccessHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlTypeHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlFixupHandler, status=200,
uri=/foo/index.pl, filename=/tmp/test_client_pub/foo/index.pl
[Wed Oct 29 17:46:35 2008] [error] A horrible, terrible death!

[Wed Oct 29 17:46:35 2008] [warn] phase=PerlLogHandler, status=200, uri=/foo/,
filename=/tmp/test_client_pub/foo/
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlLogHandler, status=200, uri=/foo/,
filename=/tmp/test_client_pub/foo/
CLEAN URI: /foo/ STATUS: 200 main: 1 initial: 1
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlCleanupHandler, status=200,
uri=/foo/, filename=/tmp/test_client_pub/foo/
[Wed Oct 29 17:46:35 2008] [warn] phase=PerlCleanupHandler, status=200,
uri=/foo/, filename=/tmp/test_client_pub/foo/

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.

--
Michael Peters
Plus Three, LP

Re: $r->status no correct

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 script with a syntax error, and I see exactly what you're
seeing. That is, when the PHP script has an error, my log handler still
sees $r->status as 200. So, $r->status is only valid for (or set by)
mod_perl response handlers which know to set it? Does this mean we
have to write an output filter to catch the status code and set
$r->status? Yikes.

Does $r->status_line also report "200"?

=46rom Apache2::RequestRec documentation for $r->status:

"Usually you will set this value indirectly by returning the status
code as the handlerâ€=99s function result."

But as I stated earlier, this is not enough (in practice)... Sounds
like more and more like a bug, which I believe is what you were
originally stating...

Re: $r->status no correct

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 for $r->status:
>=20
> "Usually you will set this value indirectly by returning the status
> code as the handlerâ€=99s function result."
>=20
> But as I stated earlier, this is not enough (in practice)

The documentation and mod_perl is correct, I am very wrong.

PS, to the reader I apologize for both the misinformation and make a
long thread longer...

Re: $r->status no correct

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() is "A horrible, terrible death!")
>
> A) /foo/index.pl
> B) /foo/

from mod_log_config.c:

* %...s: status. For requests that got internally redirected, this
* is status of the *original* request --- %...>s for the last.

for /foo/ the original request is /foo/ and the last request /foo/index.pl.

I'd check your logs but the common log format uses %>s. try
$r->last->status()

HTH

--Geoff

Re: $r->status no correct

Geoffrey Young wrote:

> I'd check your logs but the common log format uses %>s. try
> $r->last->status()

Aha! That's it, thanks a lot Geoff!

--
Michael Peters
Plus Three, LP