yes, clearly there is a bug in there, but not where you think - what is important is that apache needs to do the same thing on GET as HEAD, not that there is no C-L generated for contentless HEAD requests. this patch more accurately represents the real bug which, IIRC, httpd is already aware of (at least I'm recalling discussion about a C-L of 0).
Why do you say so? Your patch respresents a related, but a different issue. Boris has a problem with HEAD, and that's what the test was testing.
ok, maybe I was misunderstanding the discussion and subsequent test. my points are these:
- apache has essentially full reign over the C-L header - it decides whether it is required or not, regardless of whether or not you call ap_set_content_length
- more important than whether the C-L header shows up or not for a given HEAD or GET request is whether apache is consistent with itself. that is, regardless of what _you_ think it should do, apache _knows_ what it should do and should do it consistently between GET and HEAD.
See my explanation of what I think is the problem at the end of this email.
- of course, printing a C-L header to stdout works around all of this - apache can only manage things when you use the official API, since it checks the headers_out table and not the actual content.
eh? how exactly do you do that? without assbackwards ofcourse.
so, the test, as it existed before, made me think that the problem you saw
was in that final test, that adding content magically made the C-L header
appear.
Actually I the problem I saw was exactly what Boris was talking about: The C-L header wasn't there. The test simply exercises 4 different combinations of sending and not sending C-L header and content.
my point was that as long as apache does whatever it does consistently between GET and HEAD it's not a bug. but maybe I'm just not seeing it, so if you guys grok all of that and still see an issue, let's flesh it out.
I think it's there. The test that shows that is:
{
# if the response handler sends no data, and sets C-L header,
# the client doesn't get C-L header
my $uri = "$location?set_content_length";
my $res = $method->($uri);
ok t_cmp $res->code, 200, "$method $uri code";
ok t_cmp $res->header('Content-Length'), undef, "$method $uri C-L header";
ok t_cmp $res->content, "", "$method $uri content";
}
As I didn't know what's the right thing that should happen, I didn't make it a failure. But it probabaly shouldn't be undef in the C-L check.
But the fact that sending a bogus char and a different C-L header works with HEAD (gets the C-L header through), whereas not sending any output breaks, seems like a bug to me. 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.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- 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
