- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Thu, 08 Aug 1996 18:23:11 -0700
- To: hallam@etna.ai.mit.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> 3) Section 2.2 asserts that proxies typically multiplex server >> connections across multiple clients. Is this in fact the case? >> >>(Almost?) nobody yet uses proxies that support persistent connections. >>So it's hard to provide data from experience. At least, I have not >>seen any. > > My impression as well. I think that the idea that HTTP messages > should be interleavable in this manner is a very bad idea. It > is a very large cost overhead for not such a great return - unless > its done to prevent abusive clients. The normal operation for a group-to-organizational proxy or a regional-to-national proxy will be one of interleaved requests on a small number of persistent connections, with the possiblility of high performance requirements on those connections due to the bursty nature of web traffic. I do not consider that to be "typical", but it is part of the design of HTTP/1.1 and cannot be ignored without breaking the protocol. Such applications are not typical today, but they will be typical in the future (the near future given the rate at which demand is approaching network bandwidth capacity). It will happen as soon as the performance of an HTTP caching proxy exceeds that of using the network without a caching proxy. This is already the case in most areas outside the US. > I would like to suggest that we consider making HTTP a non-idempotent > protocol and introduce methods to provide transaction semantics. HTTP is already non-idempotent (POST). Do you mean stateful? > E.g. :- > > START - Begin a transaction operation > COMMIT - Commit a transaction > ROLLBACK - Undo a transaction Those are resource transactions and do not require a stateful protocol (only stateful resources, which we already have). I do expect that they will be necessary for eventual support of versioning and real distributed authoring, though loss of the connection would not imply ROLLBACK -- it would imply no COMMIT until the sequence is completed (and yes, each such request would have to carry a sequence number or the whole thing won't work). However, this is no longer relevant to the subject under discussion. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056 http://www.ics.uci.edu/~fielding/
Received on Thursday, 8 August 1996 18:37:33 UTC