Re: ISSUE: MUST a client wait for 100 when doing PUT or POST requests?

>>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.
>
>The real question that came up in the discussion, which I sent to the
>mailing list was the following:
>
>>Is it enough to rely on the half-close of the
>>connection or should the client wait for a 100 code before sending the
>>body?

That is what I was responding to. The answer is application-dependent and
not a protocol issue.  It therefore cannot be a protocol requirement.
There are many situations in which it might be a good idea, but that
is an implementation detail and one that the application designers can
figure out for themselves.

.....Roy

Received on Wednesday, 11 June 1997 12:10:46 UTC