A new suggestion on 100 CONTINUE
John Franks (john@math.nwu.edu)
Wed, 11 Jun 1997 11:27:29 -0500 (CDT)
Let me try another tack in my Quixotic fight against net litter.
Would it be acceptable to say that the server can check to see if
it has already received PUT or POST data from the client and if it
has the server MAY choose not to send "100 CONTINUE"? This would
at least permit the server not to send "100 CONTINUE" when the
POST data arrives in the same packet as some of the headers.
The changes in 8.2 of RFC2068 could be
-- old --
Upon receiving a method subject to these requirements from an
HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
respond with 100 (Continue) status and continue to read from the
input stream, or respond with an error status. If it responds with an
error status, it MAY close the transport (TCP) connection or it MAY
continue to read and discard the rest of the request. It MUST NOT
perform the requested method if it returns an error status.
-- new --
Upon receiving a request method with a body from an HTTP/1.1 (or later)
client, an HTTP/1.1 (or later) server MUST either respond with 100
(Continue) status and continue to read from the input stream, or
respond with an error status. An exception to this is if the server
has received data from the request body at the time it would respond
with 100 (Continue) then it MAY omit this response and continue to
read from the input stream. If the server responds with an error
status, it MAY close the transport (TCP) connection or it MAY continue
to read and discard the rest of the request. It MUST NOT perform the
requested method if it returns an error status.
John Franks Dept of Math. Northwestern University
john@math.nwu.edu