Re: PERSIST: Made default

On Fri, 24 May 1996, Henrik Frystyk Nielsen wrote:

> 
> These are my changes for making persistent connections the default
> behavior. 

> Henrik
> 
> 
> 17.4 Interaction with Security Protocols
> It is expected that persistent connections will operate with both SHTTP
> [31] and SSL [32]. When used in conjunction with SHTTP, the SHTTP
> request is prepared normally and the persist connection-token is placed
                                       ^^^^^^^^^^^^^^^^^^^^^^^^
Should this be the "Connection: close" header?

> in the outermost request block (the one containing the "Secure" method).
> When used in conjunction with SSL, a SSL session is started as normal
> and the first HTTP request made using SSL contains the persistent
                                                         ^^^^^^^^^^
> connection header.
  ^^^^^^^^^^^^^^^^^

Again, I think this should be the "Connection: close" as there is
no longer anything which should be called a persistent connection header.

> 
> 
> 17.5 Practical Considerations
> Servers will usually have some time-out value beyond which they will no
> longer maintain an inactive connection. Proxy servers might make this a
> higher value since it is likely that the client will be making more
> connections through the same server. The use of persistent connections
> places no requirements on the length of this time-out for either the
> client or the server.

...

> It is suggested that clients which use persistent connections SHOULD
> limit the number of simultaneous connections that they maintain to a
> given server. A single-user client SHOULD maintain AT MOST 2 connections
> with any server of proxy. A proxy SHOULD use up to 2*N connections to
                  ^^
		should be or?
> another server or proxy, where N is the number of simultaneously active
> users. These guidelines are intended to improve HTTP response times and
> avoid congestion of the Internet or other networks.
> 
> * * * * * * * * * *
> 
> 
> 23.5.2.5 Compatibility with HTTP/1.0 Persistent Connections
> + Some clients and servers may wish to be compatible with some previous
> + implementations of persistent connections in HTTP/1.0 clients and
> + servers. Persistent connections in HTTP/1.0 must be explicitly
> + negotiated as they are not the default behavior. HTTP/1.0
> + implementations are faulty, and the new facilities in HTTP/1.1 are
> + designed to rectify these problems.  The fear was that some existing
> + 1.0 clients may be sending Keep-Alive to a proxy server that doesn't
> + understand Connection, which would then erroneously forward
> 
...

> However, talking to proxies is the most important use of persistent
> connections, so that is clearly unacceptable.  Therefore, we need some
> other mechanism for indicating a persistent connection is desired, which
> is safe to use even when talking to an old proxy that ignores
> Connection.  

> As it turns out, there are two ways to accomplish that:
> 
> 1. 
>   Introduce a new keyword (persist) which is declared to be valid only
>   when received from an HTTP/1.1 message.

I think this should be removed.  The draft does not introduce a
keyword "persist".  What is the point of saying it could have?

> 
> 2. 
>   Declare persistence to be the default for HTTP/1.1 messages and
>   introduce a new keyword (close) for declaring non-persistence.
> 

This does not "solve" the problem, but there seems to be no evidence
that the problem exists (albeit some evidence that it is possible
for it to exist).  More precisely there seem to be no known clients
which send the "Connection: Keep-Alive" header to proxies, but if
there were I think that there would be a problem which 2. would not
fix.  The proxy would pass this header on to the server and a 1.1 
server (or 1.0 server supporting keep-alive) would keep the connection
open.  


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Friday, 24 May 1996 13:25:05 UTC