IPP> IPP Bake-Off 3 Implementation specific issues (5) - BO3-IMP-2: Persistent connections in HTTP1.1

IPP> IPP Bake-Off 3 Implementation specific issues (5) - BO3-IMP-2: Persistent connections in HTTP1.1

sune.pedersen at i-data.com sune.pedersen at i-data.com
Fri Oct 27 09:33:24 EDT 2000


According to RFC 2615 (Hypertext Transfer Protocol -- HTTP/1.1:

   "HTTP implementations SHOULD implement persistent connections."

It is allowed for an HTTP/1.1 server to always return a Connection header
with a "close" token, and thus not support persistent connections while
still living up to the requirements for HTTP/1.1.

>From the RFC:
***********************************************************************
8.1.2 Overall Operation

   A significant difference between HTTP/1.1 and earlier versions of
   HTTP is that persistent connections are the default behavior of any
   HTTP connection. That is, unless otherwise indicated, the client
   SHOULD assume that the server will maintain a persistent connection,
   even after error responses from the server.

   Persistent connections provide a mechanism by which a client and a
   server can signal the close of a TCP connection. This signaling takes
   place using the Connection header field (section 14.10). Once a close
   has been signaled, the client MUST NOT send any more requests on that
   connection.

8.1.2.1 Negotiation

   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
   maintain a persistent connection unless a Connection header including
   the connection-token "close" was sent in the request. If the server
   chooses to close the connection immediately after sending the
   response, it SHOULD send a Connection header including the
   connection-token close.
***********************************************************************

It is a very big SHOULD, but still, it means that it is the IPP clients
which are wrong to assume that a HTTP/1.1 server always supports persistent
connections.


/Sune




More information about the Ipp mailing list