Loading ...
Sorry, an error occurred while loading the content.

60154Re: mod_perl2, HEAD request and Content-Length

Expand Messages
  • Stas Bekman
    Aug 2, 2004
    • 0 Attachment
      Geoffrey Young wrote:
      >>>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: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
    • Show all 25 messages in this topic