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

Re: Sticky stuff.

From: <hallam@etna.ai.mit.edu>
Date: Fri, 09 Aug 96 14:09:02 -0400
Message-Id: <9608091809.AA03886@Etna.ai.mit.edu>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: hallam@etna.ai.mit.edu

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

I really object to the use of this language. To my knowledge
nobody has every produced such a server. I suspect that very
few such servers if any will ever be built.

I don't regard it as part of the "design" of HTTP/1.1 it is
simply a side effect of other considerations. At this point I
am interested in how far we can travel from our existing installed
base to where it would be nice to be. I don't think it is helpfull
to start from a theoretical projection from the existing protocol
and start complaining that software that nobody has written and
might never be written will break.

If we want to support such a mode then lets do it in a principled
way. It would be a simple matter for such a proxy to add in stream
ids.

Even more to the point such a convergence/multiplexing protocol
will suck eggs performance wise unless something like Jim 'n
Henrik's MUX layer is implemented. The requests and responses
will have to be serialized. That does not appear to me to be a 
good thing!


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

Actually as implemented GET is non-idempotent. And idempotence is
mathematically equivalent to statefull. I would like the protocol
to admit what it has been for three years and drop the idempotence
language in favour of "non-contractual" which is closer to what
Tim actually meant. 

[transaction semantics stuff]

>However, this is no longer relevant to the subject under discussion.

I think the general topic we should be addressing is the space of 
TCP/IP improvements that we can make.

I personally favour functional improvements over performance tweaks.
The Web lets me do very little of what it was originally meant to
provide. 1.1 was slated as the performance "save the net edition".
I think that we should catch up on the backlog of making the Web
a usefull tool and address functional limitations.


		Phill



		Phill
Received on Friday, 9 August 1996 11:07:15 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:06 EDT