- From: John Franks <john@math.nwu.edu>
- Date: Wed, 11 Jun 1997 11:27:29 -0500 (CDT)
- To: Henrik Frystyk Nielsen <frystyk@w3.org>
- Cc: fielding@kiwi.ICS.UCI.EDU, paulle@microsoft.com, http-wg@cuckoo.hpl.hp.com
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
Received on Wednesday, 11 June 1997 09:31:04 UTC