> As mentioned earlier I think the bug is
> in the headers_out filter, which received EOS (since on HEAD apache
> scratches the response body) and no body. So it takes the liberty to
> nuke the C-L header, which I'm not sure is a good thing. When we send
> some body, headers_out sends the headers before seeing EOS and therefore
> it can't tell whether the body is coming or not, so it leaves the C-L
> header alone. Which is at least inconsistent.
ok, I think I see what is going on, but it's different than what you see :)
first, apache calls the C-L filter, which has no regard for any existing C-L
header and calculates its own if it can. so, in your test case the call to
$r->set_content_length(25) is overwritten by the real C-L of zero, as
calculated by the C-L filter.
next the header filter kicks in. inside the header filter is this bit of logic:
if (r->header_only
&& (clheader = apr_table_get(r->headers_out, "Content-Length"))
&& !strcmp(clheader, "0")) {
apr_table_unset(r->headers_out, "Content-Length");
}
which treats HEAD requests with a C-L of zero as a special case. and, in
fact, that is what you have sent it, at least in the test case. this is why
GET and HEAD differ in this instance, because you haven't sent any real
content and a C-L of 0 is special.
so, I don't see the bug. well, I do see it, except that it is intentionally
coded to be as such, which turns the bug into a feature.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
