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: David W. Morris <dwm@xpasc.com>
Date: Wed, 11 Jun 1997 09:56:11 -0700 (PDT)
To: Scott Lawrence <lawrence@agranat.com>
Cc: HTTP Working Group List <http-wg@cuckoo.hpl.hp.com>
Message-Id: <Pine.GSO.3.96.970611093649.24946B-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3494

On Wed, 11 Jun 1997, Scott Lawrence wrote:

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

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

As I also stated in response to Paul Leach, I see little reason for
a client to pipeline past a POST or PUT request. So if we recommend
or require pausing the pipeline waiting for the response to POST or PUT
then the client makes a performance decision based on what ever
heuristics it chooses to use to declare itself waiting OR to charge ahead
knowing it will see the response, etc.  It could decide based on a
history of interaction with a particular server or URI or it could
decide based on the size of the content to be included.  The point is
that only the user of that client suffer from any transaction delays
introduced. We don't add any presumption of delay to the existing
infrastructure nor do we start transmitting useless 100 CONTINUE responses
thru an already burdened network.

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

An I'm not convinced that a generic extension to HTML to add submit
options wouldn't be a good overall strategy for this and other reasons.

One would presume that PUT and POST operations which don't result from
HTML are capable of understanding additional options associated with
PUT and POST as well.

Dave Morris 
Received on Wednesday, 11 June 1997 10:02:17 UTC

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