Re: A new suggestion on 100 CONTINUE

On Wed, 11 Jun 1997, Scott Lawrence wrote:

> 
> >>>>> "JF" == John Franks <john@math.nwu.edu> writes:
> 
> JF> Would it be acceptable to say that the server can check to see if
> JF> it has already received PUT or POST data from the client and if it
> JF> has the server MAY choose not to send "100 CONTINUE"?  This would
> JF> at least permit the server not to send "100 CONTINUE" when the
> JF> POST data arrives in the same packet as some of the headers.
> 
>   This has pretty serious implementation problems; it may be that the
>   POST has no body, and any data pending in TCP is actually another
>   request.

AHa ... a use for that extra CRLF following a POST. Just more
justification for my proposal to make the client declare if its waiting 
which I think is cleaner. 

But in any case how is this a problem for the client.  It just receives
the actual response and no 100 CONTINUE since it has nothing else to send.


>   Most of the objections raised here to all this have been to the
>   requirement that the 100 response be sent, not that the client wait
>   for it before sending the body - note that sending the 100 response
>   has been a requirement for some time.

The client wait issue was largely dealt with by Roys clarification that
clients can just ignore the issue and forge ahead.

I object to the extraneous transmissions of 100 CONTINUE.

I also object to the implication that 100 CONTINUE somehow improves 
the data transfer integrity when in fact the the real issue is that 
clients SHOULD wait for the response to a non-idempontent transaction.

Trying to somehow mitigate a problem with pipelined non-itempotent
requests is what got all of us looking closely at the rationale for
100 CONTINUE and it's implications.

Dave Morris

Received on Wednesday, 11 June 1997 10:59:43 UTC