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

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

Received on Tuesday, 10 June 1997 10:18:36 UTC