bugs

geoff on 2001-09-06T00:28:22

well, I think I found a bug in Apache today. just a minor nit really, but still...



mod_perl adds $r->as_string, which is just a nice way of listing all the HTTP related stuff about the request/response cycle (save the message bodies). it's defined in Apache.xs and just joins r->the_request, r->headers_in/out r->err_headers_out, r->protocol, and r->status_line. the problem I saw was with responses that are set using $r->custom_response - they leave r->status_line undefined, so you end up with the response message spewn from from $r->as_string looking like



HTTP/1.0 (null)



Apache seems to handle it ok, since a simple telnet shows that the 200 is coming through just fine. hmph. I wandered through http_protocol.c and http_request.c and my eyes started to cross when I tried to trace a custom response all the way through. looks like custom_response just calls an internal redirect after much fanfair, so I suspect that $r->internal_redirect may suffer as well, but I didn't verify it.



speaking of which, here are a few bugs currently on my radar



o PerlSetEnv variables seem to get lost after the first hit to a child. you can read about it here



o not really a bug, but I worked through the ability to use push/set_handlers for method handlers by reference (\&method) instead of by string ('My->method'). if you progress through the entire thread you'll see the final patch result near the end (thanks Doug for being patient :)



o HTTP::Response::base doesn't handle content negotiated documents correctly. At least that's my theory :) to see for yourself, go ahead and try the HTML::LinkExtor code example on http://httpd.apache.org/docs/ and watch what happens.
The problem is that the HTTP/1.1 RFC says Content-Location defines the base URI for the entity. However, it also says that it may contain an absolute or relative URI and, if relative, then the base is interpreted with respect to the request URI.

The offending code in HTTP::Response is

sub base
{ my $self = shift;
my $base = $self->header('Content-Base') || # used to be HTTP/1.1
$self->header('Content-Location') || # HTTP/1.1
$self->header('Base'); # HTTP/1.0
return $HTTP::URI_CLASS->new_abs($base, $self->request->uri);
# So yes, if $base is undef, the return value is effectively
# just a copy of $self->request->uri.
}
I sent a note to Gisle on 6/21/2001 to which he never responded, and the latest version of libwww-perl (5.53_96) doesn't have the fix, so I guess he didn't agree :) oh, well.

o some day I'll figure out how to implement this




by the way, I had the passing thought that using Inline::Files would give you the ability to read from __END__, which would be a cool way to handle errors...
local $/;
my $rtfm=<__END__> && die $rtfm;
untested :)