60154Re: mod_perl2, HEAD request and Content-Length
- Aug 2, 2004Geoffrey Young wrote:
>>>yes, clearly there is a bug in there, but not where you think - what isSee my explanation of what I think is the problem at the end of this email.
>>>important is that apache needs to do the same thing on GET as HEAD,
>>>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
> - 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.
> - of course, printing a C-L header to stdout works around all of this -eh? how exactly do you do that? without assbackwards ofcourse.
> apache can only manage things when you use the official API, since it checks
> the headers_out table and not the actual content.
> so, the test, as it existed before, made me think that the problem you sawActually I the problem I saw was exactly what Boris was talking about:
> was in that final test, that adding content magically made the C-L header
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 doesI think it's there. The test that shows that is:
> 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.
# 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
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:stas@... 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
- << Previous post in topic Next post in topic >>