Re: A new suggestion on 100 CONTINUE

On Wed, 11 Jun 1997, Roy T. Fielding wrote:

> >
> >This does illustrate my point though.  Isn't it a little bit brain dead
> >to *require* a "100 CONTINUE" for a POST with no body?
> 
> That is brain dead.  The intended requirement was that it apply to
> any request that includes a message body and not be tied to the method
> definition at all.
> 

Good point.  I modified my suggested changes to 8.2 to take account of
this.  You didn't comment on these suggested changes though and I
would be interested in your thoughts.  While in the best of all
possible worlds David Morris's suggestion of a new header would be
somewhat preferable, I think at this point the change below might be
our best course.  It buys most of the improved efficiency.  It is
completely compatible with any existing implementations of RFC2068.
It is easy to implement (at least on platforms I know something
about).


The change in 8.2 of RFC2068 should 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 with a non-empty 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 13:57:37 UTC