Re: A new suggestion on 100 CONTINUE
David W. Morris (dwm@xpasc.com)
Wed, 11 Jun 1997 10:54:27 -0700 (PDT)
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