httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 47087] New: Incorrect request body handling with Expect: 100-continue if the client does not receive a transmitted 300 or 400 response prior to sending its body
Date Thu, 23 Apr 2009 23:08:37 GMT

           Summary: Incorrect request body handling with Expect:
                    100-continue if the client does not receive a
                    transmitted 300 or 400 response prior to sending its
           Product: Apache httpd-2
           Version: 2.2.11
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core

when responding to a HTTP request that has the following headers:

Expect: 100-continue
Transfer-Encoding: chunked

if the response is anything other than simply "100 Continue" (e.g. if the
response is 302 redirect or 401 authorization required), the server interprets
any body elements in the request as being part of a new request instead of
discarding the chunks.

The scenario is as follows:
The client transmits:

POST /RedirectedLocation HTTP/1.1
Host: localhost:9999
User-Agent: MyAgent/1.1
Content-Type: multipart/form-data; boundary=Boundary1240524002
Transfer-Encoding: chunked
Expect: 100-continue

The server immediately responds with something like:
HTTP/1.1 302 Found
Date: Thu, 23 Apr 2009 22:00:05 GMT
Server: Apache
Location: /newLocation
Content-Length: 257
Keep-Alive: timeout=10, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<title>302 Found</title>
<p>The document has moved <a href="/newLocation">here</a>.</p>
<address>Apache Server at localhost Port 9999</address>

However, in this scenario due to network lag, this response is not received by
the client before its timeout period expires waiting for the 100 continue or
for another response.  Therefore, having not received the response, the client
begins to send the body:

Content-Disposition: form-data; name="FileName"

At this point, the client receives the 302 response and stops transmitting by
sending this:


However, the Apache server responds with the following:
NOTE: there is no HTTP header information associated with the rest of the
response and it appears that the server is treating the chunk size "49" as an
unknown HTTP method

<title>501 Method Not Implemented</title>
<h1>Method Not Implemented</h1>
<p>49 to /index.htm not supported.<br />
<address>Apache Server at myserver Port 9999</address>

It looks like RFC2616 section 8.2.3 Use of the 100 (Continue) Status
(, is indeterminate in this matter. 
However, I believe the current behavior is incorrect given that HTML data is
being sent across the wire without an associated HTTP header that would
indicate its content-length or chunked encoding.

I would propose that the correct behavior would be to either wait for and
discard the rest of the response or close the connection.  This seems to be in
line with what is said about this in the RFC (relevant section delimited by

Upon receiving a request which includes an Expect request-header field with the
"100-continue" expectation, an origin server MUST either respond with 100
(Continue) status and continue to read from the input stream, or respond with a
final status code. The origin server MUST NOT wait for the request body before
sending the 100 (Continue) response.  >>>>>>If it responds with a final
code, it MAY close the transport connection or it MAY continue to read and
discard the rest of the request.<<<<<<  It MUST NOT perform the requested
method if it returns a final status code.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message