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

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

From: Scott Lawrence <lawrence@agranat.com>
Date: Wed, 11 Jun 1997 13:34:58 -0400
Message-Id: <199706111734.NAA07774@devnix.agranat.com>
To: "David W. Morris" <dwm@xpasc.com>
Cc: Scott Lawrence <lawrence@agranat.com>, HTTP Working Group List <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3497

SL> On Wed, 11 Jun 1997, Scott Lawrence wrote:

SL> On what basis should the client decide that waiting for the 100 is
SL> important for the current PUT or POST?  The client does not have any
SL> way to know what the specific semantics of the operation are.  In
SL> fact, the server often will not know either - it is just serving a
SL> form.  Even adding HTML markup (which I am NOT advocating) would not
SL> solve the problem, as not all PUT and POST operations will be a
SL> result of the use of HTML.

>>>>> "DM" == "David W Morris" <dwm@xpasc.com> writes:

DM> On the same basis that Roy Fielding and others have advocated that a
DM> client designer could decide not to wait for the 100 CONTINUE.

  What we are discussing is adding the requirement that the client
  wait - specifically because not waiting makes the 100 response
  useless (and we have pointed out ways in which is it usefull if and
  only if the wait is required).

DM> I see little reason for a client to pipeline past a POST or PUT request.

  I (and Steve Wingard from Spyglass) pointed out a scenario unrelated
  to pipelining in which the 100 is usefull in _reducing_ network

DM> It seems silly to design a protocol to support a requirement when neither
DM> the client nor the server know that the feature is required. I would
DM> assert that only specialized clients and servers need this feature and
DM> they will know by mutual agreement that it is required.

  We have been discussing specific cases in which _general_purpose_
  clients need this feature.  The client is a web browser, and (at the
  risk of repeating myself) there exists no mechanism for the server
  (specialized or otherwise) to indicate that the mechanism _is_

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Wednesday, 11 June 1997 10:40:03 UTC

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