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: David W. Morris <dwm@xpasc.com>
Date: Tue, 10 Jun 1997 09:58:17 -0700 (PDT)
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg@cuckoo.hpl.hp.com, lawrence@agranat.com, rlgray@raleigh.ibm.com
Message-Id: <Pine.GSO.3.96.970610094749.29833B-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3457

On Tue, 10 Jun 1997, Henrik Frystyk Nielsen 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? 

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

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.

Dave Morris
Received on Tuesday, 10 June 1997 10:25:28 UTC

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