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

Re: Sticky stuff.

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
Message-Id: <9608081823.aa22128@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1265
>>    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
Received on Thursday, 8 August 1996 18:37:33 UTC

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