httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27966] New: - Expect: 100-continue not honored for Content-Length: 0
Date Thu, 25 Mar 2004 23:04:27 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27966>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27966

Expect: 100-continue not honored for Content-Length: 0

           Summary: Expect: 100-continue not honored for Content-Length: 0
           Product: Apache httpd-2.0
           Version: 2.0.49
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: All
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: alexp@hubspan.com
                CC: alexp@hubspan.com


When a POST or PUT is made with Expect: 100-continue and
Content-Length: 0, then Apache immediately replies with
200 OK instead of first sending 100 Continue.

By RFC 2616, section 4.3, an empty message body is still
a message body.  By section 8.2.3, the only valid responses
after Expect: 100-continue are 100 Continue or a final status
code... but if a final status code is given then the server
MUST NOT perform the requested method, implying that 200 OK
is not valid.  (Apache does in fact perform the requested
POST, returning the script output, if appropriately configured.)

The RFC does say that the server MAY omit the 100 Continue
response if it has received all of the request body (which
it certainly has if the Content-Length is 0)... but I believe
that the MUST NOT (perform...) overrides the MAY, so in all
cases leading to 200 OK, a 100 Continue must be sent.

There is a workaround: the client should not send a 100-continue
expectation with a Content-Length: 0.  This may or may not be
easy to implement for arbitrary clients.  (It is a moderate
nuisance for my code which provoked this bug report.)

I have reproduced this bug under WindowsNT; I have no reason
to believe that it is platform-specific, but don't have a
convenient place to test for any other platform.

A simple perl script to exercise the problem follows.

- Alex

#!/bin/perl

use IO::Socket::INET;

$where = "localhost:8080";
$sock = IO::Socket::INET->new($where);

print $sock <<"EOT";
POST /foo.pl HTTP/1.1
Host: $where
Content-Length: 0
Expect: 100-continue
Connection: keep-alive
User-Agent: My stupid test agent


EOT

while ($line = <$sock>) {
  print $line;
  if ($line =~ /^HTTP\/1.1 100/o) {
    print "Got the continue.\n";
    exit(0);
  }
  if ($line =~ /^HTTP\/1.1 417/o) {
    print "Got a reasonable expectation failure.\n";
    exit(0);
  }
  if ($line =~ /^HTTP\/1.1 200/o) {
    print "BUSTED!  Need to deal with the continue expectation before giving 
success!\n";
    exit(1);
  }
}

print "Hrm.  Something unexpected happened, probably bad.\n";
exit(1);

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message