W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: A new suggestion on 100 CONTINUE

From: David W. Morris <dwm@xpasc.com>
Date: Wed, 11 Jun 1997 10:54:27 -0700 (PDT)
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970611104709.24946E-100000@shell1.aimnet.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3502

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC