Re: holding connections open: a modest proposal

Dave Kristol (
Tue, 13 Sep 1994 15:05:43 +0200

Marc VanHeyningen <> said:
> Dave Kristol said:
> >There has been some discussion here about keeping connections open
> >between client and server after a transaction is complete. I don't
> >recall seeing a resolution, however, so I want to put forth what I
> >think is a simple solution, and I don't recall seeing anything
> >comparable proposed.
> Re the original proposal, the main thing missing is specification of
> headers; the "Content-Length" header becomes mandatory whenever it is
> nonzero if multiple transactions are happening.
> For that matter, the general semantics of headers becomes a bit less
> clear. Should request headers be re-transmitted by the client with
> each request or be assumed by the server to remain the same from
> request to request, for instance? Which ones?
My intent was to treat each follow-up GET as a new transaction.

I think people have gotten too bogged down in the minutiae of my proposal.
The big picture is for clients and servers to behave as they do now, except
that instead of closing the client-server connection, leave it open (a
SHORT time) to see if another transaction between the same parties will
follow. The SHORT time is enough to allow the client to decide to download
images (typically) and make a new GET request, just as it would do now.
Unlike now, there would be an open connection on which to do it, so the
setup time for a connection (and the tear-down time for the previous one)
are saved.

Larry Masinter <> says:
> Aren't there possible race conditions, where the server decides to
> shut down the connection just as the client sends the second GET?

Indeed. The only race condition of interest is where the client starts
a new request just as the server is shutting down the connection. But
because the proposal I put forth essentially reverts to current
behavior (open a new connection, make a request, etc.) on a dropped
connection, the recovery method is hardly more burdensome than what
happens now.

I want to emphasize again that I have in mind a SMALL change. The
reason is simple. With this small change we can make evolutionary
changes to the components we have, without introducing a stage where
old versions of a client or server can't talk to the new versions.
Other proposals (except Pragma: Keep-connection; I guess my proposal is
equivalent to an implicit Pragma: Keep-connection.), however
sophisticated (and complicated), introduce incompatibities, and are
therefore less desirable.

Dave Kristol