> >* Despite numerous heroic efforts, HTTP HEAD requests are still screwed! > >Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry > >doesn't work with redirects and 404's (I get like two headers and 3 > >bodies for 404's. Now that's verbose :-)) > > > No real mod_perl problem on that - that's a problem (or maybe > intentional functionality?) in Apache::Registry and Apache::HEADRegistry...
actually, on this particular issue I think it is a design problem on mod_perl's part. if anyone is interested, he's my analysis... I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). the assbackward flag means that Apache will forego sending headers itself. I think I understand Doug's logic in the code: send_cgi_header() prints the headers directly to the client, instead of setting $r->headers_out->set() and letting Apache do it, which is more like the way mod_cgi works. anyway, r->assbackward is a hack that mod_perl uses in a few places. the problem with messing with r->assbackward is that it really signifies an HTTP/0.9 response, for which GET is the only option, not HEAD. so... the normal Apache logic that cuts the body of the response out of a HEAD request (by checking r->header_only) is circumvented when r->assbackward is set. And, since Apache sends the body for REDIRECT and other "errors" (and not mod_perl) Apache doesn't know to _not_ send the body. get it? the routines in question are ap_send_error_response() in http_protocol.c and send_cgi_header() in Apache/Apache.pm (which calls mod_perl_sent_header() in mod_perl.c, which sets r->assbackward). I'm not sure if it is possible to easily work around this, but that's what I've come up with so far if anyone else wants to tackle this particular issue... --Geoff
