RE: ISSUE: MUST a client wait for 100 when doing PUT or POST re
Paul Leach (paulle@microsoft.com)
Tue, 10 Jun 1997 16:26:46 -0700
This example only seems to require that the client wait for 100 if it is
pipelining -- otherwise it won't know which (possibly non-idempotent)
requests have or haven't been processed, which is a correctness problem.
Other scenarios show that efficiency might suffer if the client didn't
wait for a 100.
Are there any other scenarios where _correctness_ is affected by not
waiting?
> ----------
> From: Henrik Frystyk Nielsen[SMTP:frystyk@w3.org]
> Sent: Tuesday, June 10, 1997 11:10 AM
> To: John Franks
> Cc: David W. Morris; http-wg@cuckoo.hpl.hp.com;
> lawrence@agranat.com; rlgray@raleigh.ibm.com
> Subject: Re: ISSUE: MUST a client wait for 100 when doing PUT or
> POST requests?
>
> At 12:50 PM 6/10/97 -0500, John Franks wrote:
>
> >> 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.
> >>
> >
> >Could you explain why trans-Atlantic POSTs would be more reliable
> with
> >100 Continue? I honestly don't understand.
>
> A typical HTTP request header is small enough to not force a TCP reset
> which may cause the HTTP response to get lost. As I said in my first
> mail,
> the problem is illustrated in the connection draft, section 8:
>
> The scenario is as follows: an HTTP/1.1 client talking to a
> HTTP/1.1
> server starts pipelining a batch of requests, for example 15 on an
> open TCP connection. The server decides that it will not serve
> more
> than 5 requests per connection and closes the TCP connection in
> both
> directions after it successfully has served the first five
> requests.
> The remaining 10 requests that are already sent from the client
> will
> along with client generated TCP ACK packets arrive on a closed port
> on the server. This "extra" data causes the server's TCP to issue a
> reset which makes the client TCP stack pass the last ACK'ed packet
> to
> the client application and discard all other packets. This means
> that
> HTTP responses that are either being received or already have been
> received successfully but haven't been ACK'ed will be dropped by
> the
> client TCP. In this situation the client does not have any means of
> finding out which HTTP messages were successful or even why the
> server closed the connection. The server may have generated a
>
> In general, the problem can occur if the client sends a lot of data
> and the
> server closes the connection before having read the whole bit.
>
> >Here is my point. Superficially HTTP/1.0 POSTS seems to work well.
> >The proposed change seems likely to cause a dramatic degredation of
> >service. I suspect that it will always be fairly rare for a server
> to
> >reject a POST. Do we really have evidence that requiring 100
> Continue
> >for every POST is a good thing?
>
> I don't believe I said that - the proposed resolution was:
>
> 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.
>
> This covers exactly the situation of small POST requests, you are
> referring
> to. I believe that being conservative in the specification
> guaranteeing
> correct behavior but allowing optimized applications is better than
> the
> other way round.
>
> Thanks,
>
> Henrik
> --
> Henrik Frystyk Nielsen, <frystyk@w3.org>
> World Wide Web Consortium
> http://www.w3.org/People/Frystyk
>