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: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Tue, 10 Jun 1997 13:09:48 -0400
Message-Id: <>
To: "David W. Morris" <dwm@xpasc.com>
Cc: http-wg@cuckoo.hpl.hp.com, lawrence@agranat.com, rlgray@raleigh.ibm.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3458
At 09:58 AM 6/10/97 -0700, David W. Morris wrote:

>> I think, we are coming down on the side saying that a client SHOULD wait
>> for a 100 (Continue) code before sending the body but can send the whole
>> thing if it believes that the server will react properly. There should also
>> be a compatibility note with HTTP/1.0 servers. When talking to a HTTP/1.0
>> server, the only way a client reliably can avoid a TCP reset is to send the
>> headers and pause before sending the body.
>Since when do HTTP/1.0 servers send 100 Continue? 

I don't believe I said that.

>The whole notion of insertion of arbitrary delays offends me. The
>randomness of network latency makes that absurd. 

Yes, but unfortunately, HTTP/1.0 is broken and this is the only way to get
PUT to work reliably. If you have ever tried to PUT across the Atlantic
then you would know what I am talking about.

>As I recall the prior
>debates, we converged on a solution which only utilized the delay as 
>part of a backoff and retry algorithm. I believe that the situation
>is broken enough that when a server can't handle a large request when
>first submitted, the loss of a connection is a small part of the 
>cost and overhead and not worth optimizing in terms of either design
>effort of implementation complexity.  We don't have a two phase commit
>protocol and we don't have a pre-approval protocal though both can be
>built using existing support between a client and a server which mutually
>agree to a particular application of HTTP.

I think you missed my point: There are two situations here - PUT against
HTTP/1.0 and HTTP/1.1. For HTTP/1.0 you have to step carefully and hope for
the best. Arbitrary delays are not part of the HTTP/1.1 solution. The
reason why we can do better is that we have the 100 code which avoids
arbitrary delays and prematurely closed connections. 


Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
Received on Tuesday, 10 June 1997 10:18:36 UTC

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