W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

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

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Wed, 11 Jun 1997 11:19:54 -0700
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9706111119.aa24921@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3507
>>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

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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC