Persistent Connections - Mandating who closes?

HTTP/1.1 draft 7 (RFC to be) makes no recommendation on which of client or
server should close the transport connection after a response has finished
which included a "Connection: close" in either request or response.

>From a TCP perspective, this is v. significant. First end to close has to go
into (typically) 4 min. TIME-WAIT state continuing to reserve the RAM
associated with the control block etc. Obviously the spec. has to allow
either end to close the transport connection, but it should be possible to
mandate that to even be stamped "conditionally compliance" a client
implementation MUST be responsible for closing the transport connection in
response to a "Connection: close" header, but it SHOULD also be able to
handle the server closing the transport connection. Otherwise, the "problem
of the commons" says the client won't close it unless the standard tells it
to. Mandating such asymmetry would spread the cost of the few extra bytes
needed for each connection in TIME-WAIT across the large number of users,
instead of the smaller number of server operators. This should reduce the
total cost of the Web to the world (taking into account that server
operators recover their costs from users).

If this is what the spec is meant to say, it doesn't read that way to me. If
it wasn't meant to say this, then surely it's not too late to open up a
debate as to whether it should say this?

BTW, I've checked and can find no mention of this in the list archives.

Bob
____________________________________________________________________________
From:    Bob Briscoe,                                BT, Distributed Systems
Post:    B54 74, BT Labs,    Martlesham Heath,   Ipswich, IP5 7RE,   England
E-Mail:  rbriscoe@jungle.bt.co.uk
Tel:     +44 1473 645196                                Fax: +44 1473 640929
WWW:     http://www.jungle.bt.co.uk/people/rbriscoe.html  (BT intranet only)

Received on Friday, 25 October 1996 09:55:58 UTC