Re: ISSUE: MUST a client wait for 100 when doing PUT or POST
Henrik Frystyk Nielsen (frystyk@w3.org)
Tue, 10 Jun 1997 13:09:48 -0400
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.
Thanks,
Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk