Re: PERSIST: headers needed at all?

    Suppose we decreed that all HTTP/1.1 agents understand persistent
    connections, without requiring them to pass special headers.  We also
    grant clients and servers the right to close connections at their
    discretion following a request/response exchange (as we already do).
This has some obvious attractions, but before we took this step
we would have to get consensus on two issues:

	(1) all server (and cache) implementors would have to agree
	that they are willing to implement persistent connections.  So
	far, we've operated under the assumption that this is
	optional, so we have not tried to obtain near-unanimous consent.
	(2) more subtly, the existing proposal does not allow a client
	to pipeline its requests unless it has received a Persist:
	header from the server.  "Pipeline" means "send multiple
	requests before receiving any responses.  So we would also have
	to make sure that there was never any reason that a 1.1 server
	could not handle such behavior.  As I said, up to now we
	have not tried to obtain near-unanimous consent for this.

I'm not myself opposed to your proposal, but I'm not interested in
spending a lot of time arguing about it if there are people opposed
to it.

    Dropping the Connection header would simplify the protocol.  Why not?

The Connection header is there for orthogonal extensibility reasons.
Its purpose is to allow HTTP/1.1 caches to ignore future hop-by-hop
headers that may be defined in HTTP/1.x.  Roy added it to HTTP/1.1
because he observed that if it had been in HTTP/1.0, we could have
more easily added persistent-connection support in a compatible way.


Received on Monday, 15 April 1996 16:38:28 UTC