Persistent connections

• Close connection between objects? Semantics?

1. Proxy-connection header?
2. How responses should be terminated
3. sticky headers
4. Eliminate "max" and "timeout".

   We believe that no clients actually use the "max" and "timeout" parameters of the Keep-Alive: header, nor did anyone argue that these were particularly useful. So we will recommend that servers should not send them (but may send them), and clients should ignore them.

5. Although the Keep-Alive: proposal was meant to be experimental, some vendors now have an installed base of software that implements this header.
   continue to use it as currently understood.
   However, HTTP/1.1 clients (and HTTP/1.1 proxies acting as clients) MUST NOT send Keep-Alive: to a proxy (of any version), because of the danger that an HTTP/1.0 proxy will forward it improperly.

   Instead, HTTP/1.1 clients (and HTTP/1.1 proxies acting as clients) wishing for a persistent connection should send:
   Persist: <name of server or proxy>
   Connection: Persist
   in their request. The <name of server or proxy> is the DNS name or IP (v4 or v6) address of the server/proxy that the client believes it is sending the request to. Since the server/proxy knows its own name(s), there is no DNS lookup required here, and it works for clients using SOCKS to get through a firewall. And since an IP address (in v4 or v6 notation) is usually legal wherever a DNS name would be, we must allow addresses here.

   [Note: "Persist:" was called "Alex:" at the meeting and in the minutes, for reasons not worth elaborating upon.]

   If a server/proxy receives a request with a Persist: header carrying the wrong name (not one of the names that it goes by), it MUST NOT create a persistent connection.

   Otherwise, a server/proxy responds with
   Persist:
   Connection: Persist
   if it agrees to create a persistent connection.

   An HTTP/1.1 client or proxy may send
   Keep-Alive:
   Persist: <name of server or proxy>
   Connection: Keep-Alive, Persist
   

   to an origin server (but NOT to a proxy). This allows it to request a persist connection from either an HTTP/1.1 or HTTP/1.0+keepalive server without knowing in advance what the server type is. If the server supports both mechanisms, it should respond with
   Keep-Alive:
   Persist:
   Connection: Keep-Alive, Persist

   This combined behavior should also help in the case where an origin server is hidden behind a SOCKS or network address translation system, and consequently has the "wrong" name. However, this is not a complete solution (e.g, a proxy hidden behind a NAT system will not accept Persist:).

   A client that "learns" that a server supports Persist: could refrain from sending Keep-Alive: in the future, to avoid the extra overhead.

   An HTTP/1.1 proxy that receives a Keep-alive: request from an HTTP/1.1 client or proxy MUST NOT create a persistent connection; this event indicates that something has gone wrong somewhere.

6. Persistent connections are meant in part to support pipelining of requests and responses. However, a client MUST NOT pipeline its requests until the server has indicated that it will create a persistent connection. We believe that otherwise, certain servers or proxies could become confused. We will allow a client to remember that a given server has recently allowed persistent connections (say, within the past 1 day).
7. We expect that a server will always try to serve at least one request on any connection. This rule should prevent livelock (lack of progress) even if the server is aggressively closing connections.
8. We agreed that although persistent connections are meant to encourage browsers to use as few simultaneous connections as possible, we could not insist on any specific small number. It appears that (in order to provide early rendering of images in a large HTML file) two connections may be required in some cases.
9. Some "images" have effectively infinite length. This causes problems for any browser that supports a finite number of connections. We discussed this and I recall that there was a vague proposal to allow servers to mark such "infinite" responses in the response headers (allowing the browser to not serialize other retrievals behind the infinite one), but I cannot recall if we reached any conclusion on this.
10. If a user wants to abort a retrieval in progress, we agreed that the most reasonable approach would be to close or reset the connection. This means that a server should be able to deal with a closed or reset connection without undue suffering.

We have a few remaining action items:

• Alex will work on a "sticky headers" proposal, to replace his "Maintain:" proposal. We agreed that sticky headers and persistent connections should be handled with separate header names, to allow some orthogonality in the spec and implementation.
• After some discussion of Chunked transfer encodings and MIME Multipart encodings, we agreed that Alex, Lou Montulli, and Roy Fielding would discuss this among themselves and try to reach a consensus. We agreed (if I recall correctly) that we had to ensure that a server could send at least one of these and be sure that the client/proxies would know what to do with it!