W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Connection Header

From: Ari Luotonen <luotonen@neon.mcom.com>
Date: Mon, 19 Dec 1994 03:41:27 -0800 (PST)
Message-Id: <199412191141.DAA17810@neon.mcom.com>
To: frystyk@www0.cern.ch
Cc: john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

> > The criticism of MGET that it is not as general as keep-open is true,
> > but I think there is serious danger of performance degradation if that
> > generality is used.
> I don't quite follow, could you please give some examples?

If you use Connection, then the server process stays active for quite
a long time.  If you use MGET the processing still happens in batch
mode, and you get to exploit the TCP kernels buffering quite a lot.
That's a big win, and losing that would hit hard on all servers.  In
fact, I'm fearing that this would make the situation worse from the
servers' point of view, rather than alleviate it (this would require
someone doing some load testing).

> I can see several things that I would like to do. First, it would be
> nice to use the Web to have destributed code development. When you
> check in your files in a remote code management system, you can use
> PUT. Now, as you often have a lot of files, it would be great to do all
> this using one connection.

This is a couple of orders of magnitude smaller problem -- you PUT
files a lot less than people GET them (at least I wouldn't want to be
the webmaster of such an unpopular site...).  Even then you can have
an MPUT.  I have a hard time imagining that someone would
realistically do multiple GETs/POSTs/PUTs intermixed.  Really.

> In the spec we have done a great deal of work trying to give the
> client the same possibilities as the server and we should not limit
> this using MGET, MHEAD, MPUT etc.

Make the most common cases fast and easy, don't burden them with
extra, frankly unnessary flexibility to accommodate with every
possible (unused) combination.

> In the next six months you will see many clients being a lot more
> interactive

Then we'll use a new generation of HTTP.  Now we're talking about
HTTP/1.1 (we are, aren't we??), that would be a relatively small step
from 1.0 and would solve a just the worst problems that we're now
facing with 1.0.

> > Netscape obtains with multiple connections is not viable. It's a
> As I wrote in an earlier mail: This is ok if one does it, but if
> everybody does it then they all loose. In other words: it must be
> scalable!

This is not a scalability issue -- your GUI client fetches the images,
one way or another.  You'll have a small overhead (1 connection) or a
little larger overhead (1 connection per image), but this is not
exponential.  Scalability problems come from somewhere else, and
fetching inlined images with a lower overhead will only slightly
prolong the time it takes to hit that bottleneck.

Ari Luotonen				http://home.mcom.com/people/ari/
Netscape Communications Corp.
650 Castro Street, Suite 500
Mountain View, CA 94041, USA
Received on Monday, 19 December 1994 03:42:04 UTC

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