Re: Connection Header

/*
 * "Re: Connection Header" by john@math.nwu.edu (John Franks)
 *    written Sun, 18 Dec 1994 09:55:02 -0600 (CST)
 * 
 * According to Henrik Frystyk Nielsen:
 **  Using Allow has the same problem as if a Connection header is
 ** passed through a proxy. Imagine the following setup
 ** 
 ** new client -> old proxy -> new server
 ** 
 ** On the first request, the new server will then send back a
 ** 
 ** Allow: GET, MGET, HEAD, etc.
 ** 
 ** On the second request, the new client will try a MGET, but the
 ** proxy doesn't understand this and then we are back to the old
 ** problem having lost one roundtrip time.
 *
 * I don't see this as a very big problem.  We have lost one roundtrip
 * time, but only a roundtrip between client and proxy.  In normal use
 * client and proxy are very close with low latency.  I don't think
 * this is a very big price to pay.  This proposal then has the big
 * advantage that it is backwards compatible.  It isn't necessary to
 * try to change HTTP1.0 proxies to get them to strip out anything. (I
 * am assuming that current proxies will return a standard error
 * status/message for an unrecognized method.)

This is true, but why not modify either Connection or Allow:MGET so
they are ignored when a client is talking to a proxy? That is, if I'm
a Connection or Allow:MGET aware client, I ignore these headers unless
I also get Proxy-connection or Proxy-allow:MGET?

 * 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.  More likely unless those
 * concerns can be met keep-open would not be widely implemented.

I agree... for instance, I'm not sure how I would implement something
to keep track of how idle multiple server processes are without using
shared memory or writable mmap()ed files, which I already have found
are not available on certain platforms we support...

 * I would assume that an MGET addition to the protocol would be
 * accompanied by a parallel MHEAD method.  It would still not be
 * possible to mix GETs and POSTs or even do multiple POSTs. I don't
 * see any pressing demand for these, but perhaps I am just not aware
 * of it.

I'm not sure where the demand for this is either... The generality of
a session seems to me to be not that great a win if the session is
still a batch request-response cycle. I'd rather have real sessions
similar to what Simon proposes in HTTP-NG, where we can have
interactive stock quotes streaming in through one window while at the
same time the user is browsing the same server's other HTML documents,
all in one connection.

 * There is an important principle to keep in mind here.  Any proposal
 * that can't at least match the user's perceived performance which
 * Netscape obtains with multiple connections is not viable. It's a
 * competitive world out there and browser writers will have to go
 * with multiple connections if nothing else matches their
 * performance.  Any proposed standard, MGET or stay-open, which can't
 * measure up to multiple connection performance just won't be
 * implemented.
 */

Yes, and to that end we have to keep in mind that while <img width=N
height=M> is useful, it means that in order to see that performance
win, everyone has to edit their HTML. That will take time, and
Netscape's perceived performance works everywhere without having to
edit (or parse) every single HTML doc on a server...

--Rob

Received on Sunday, 18 December 1994 15:21:52 UTC