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

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
  traffic.

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_
  required.

--
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