- 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
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