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