RE: MUST a client wait for 100 when doing PUT or POST?

Here is a summary of the 100 Continue discussion:

Henrik Frystyk Nielsen explained the problem:  If a server opts to
refuse a POST or PUT and the client has already begun sending the
data, any error message sent by the server may get lost.

RFC2068 is, in the opinion of many, not very clear on the purpose of
"100 CONTINUE" or the requirements for the client side of the transaction.
However Roy Fielding explained the intent:

  "The *choice* of whether or not the client waits for the 100 response
  is not an interoperability requirement.  If an application has reason
  to expect that the server will accept the request and read the incoming
  data before closing (as is the case for existing POST requests to a
  CGI script) or if the application doesn't mind receiving a reset and
  repeating the request at a slower rate the second time, then it does
  not need to wait for the 100.  If, however, it is an application that
  wants to test the waters before diving in, then it can wait for the 100..
  Neither case impacts the interoperability between client and server."


In other words in the case when a server rejects a PUT or POST based
on header information (e.g. Content-Length) the client has the choice
to use a mechanism which will reliably allow it to receive the 
server's error message.

I have tried to raise the question, "Are we sure that the cure is
not worse than the disease?"

We should be very clear on the consequences of server requirements
in RFC2068.  The server must respond to *every* PUT and POST with
a "100 CONTINUE" or an error status.  It is my belief that 99% of
these transactions will be useless and will be ignored by the recipient.

Keep in mind that this requirement will likely add one unused server
response to *every* electronic commericial transaction.  In an
intranet setting *every* request for information from a data base using
a POST will have an additional useless transaction added.

Surely this is a serious wart on HTTP/1.1.  I hope we can do something
about it.

On Tue, 10 Jun 1997, David W. Morris wrote:

> I think that combined with making the 100 CONTINUE an explicitly requested
> optional response would provide the step wise operation which would
> provide the efficiency when needed by assuring the client the ability to
> expect the 100 CONTINUE but have no requirement for any server to always
> response with 100 CONTINUE. I think a win-win.
> 
> 

This is an eminently sensible idea.  The client could *choose* to wait
for "100 CONTINUE" and signal this choice to the server with an
appropriate header.  99% of the POST and PUT requests will not choose
to do so.  The server MUST send "100 CONTINUE" if it receives this
header and MAY do so in any case.  The client MUST wait for "100
CONTINUE" if it has sent the header signaling its intent to do so. The
point of the MAY is to make (existing) servers which always send "100
CONTINUE" compliant.

I agree with David this would be a win-win.



John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Wednesday, 11 June 1997 07:26:09 UTC