IPP Mail Archive: Re: IPP> IPP Bake-Off 3 Implementation spe

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

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

  • Next message: Zehler, Peter: "IPP> IPP Bake-Off 3 Summary"

    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. 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


    This archive was generated by hypermail 2b29 : Fri Oct 27 2000 - 10:22:45 EDT