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:44:48 -0700 (PDT)
To: George Carrette <George_Carrette@iacnet.com>
Cc: John Franks <john@iacnet.com>, Henrik Frystyk Nielsen <frystyk@iacnet.com>, fielding <fielding@iacnet.com>, paulle <paulle@iacnet.com>, http-wg <http-wg@iacnet.com>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970611103659.24946D-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3501

On Wed, 11 Jun 1997, George Carrette wrote:

> John, your optimization suggestion:
> >>This would at least permit the server not to send "100 CONTINUE" when the
> >>POST data arrives in the same packet as some of the headers.
> seems non-robust enough with respect to variations in network
> and operating system conditions that it could be seriously troublesome.
> There must be a better way that doesn't cross abstraction (whatever)
> layers like that.

I don't believe 100 CONTINUE contributes to robustness and this change
certainly can't hurt robustness. 
  a.  A CLIENT is required to ignore an undesired 100 CONTINUE
  b.  This option only suppresses 100 CONTINUE when the server has
      absolute proof that the client isn't waiting.  If the server
      receives a single byte of data past the headers, by definition
      one of two things has happened:
      1.  The client didn't wait
      2.  There is a program bug somewhere (e.g., the client dribbled
          and then waited or a network router or TCP stack inserted data)
It is almost trivial for a server to make the decision and for otherwise
correctly behaving software, the only possiblity is that some number
of 100 CONTINUEs will still be unnecessary but I'd bet the percentage
would be less than 10% as opposed to the 95% or greater for the current

Dave Morris 
Received on Wednesday, 11 June 1997 10:50:19 UTC

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