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

On Tue, 10 Jun 1997, Henrik Frystyk Nielsen wrote:

> At 12:50 PM 6/10/97 -0500, John Franks wrote:
> 
> >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.
> 

But there is no comparable way out for the server.  The server MUST
send 100 Continue even if the POST data is three bytes.  This will
be an inordinately wasteful solution if (as I suspect) we will never
see even 0.1% of the POSTS needing this additional transaction.

Also as an implementer I am always bothered by sentences like

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

What is the basis of the client's belief that the server will react
properly?  What does that even mean?  You explained that small POSTS
are ok, but how small?  I would find it acceptable to specify a size
and say the POSTS and PUTS larger than that size (or using chunked)
require 100 Continue and others don't.


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Tuesday, 10 June 1997 11:46:38 UTC