IPP Mail Archive: IPP> Re: IPP PRO HTTP Connection: close

IPP Mail Archive: IPP> Re: IPP PRO HTTP Connection: close

IPP> Re: IPP PRO HTTP Connection: close

Peter Michalek (peterm@shinesoft.com)
Fri, 18 Sep 1998 06:44:03 -0700

-----Original Message-----
From: Carl Kugler <kugler@us.ibm.com>
To: ipp@@pwg.org <ipp@@pwg.org>
Date: Thursday, September 17, 1998 9:21 AM
Subject: IPP> Re: IPP PRO HTTP Connection: close

>Re: PWG IPP PRO HTTP Connection: close
>Carl Kugler (kugler@us.ibm.com)
>Wed, 9 Sep 1998 16:53:39 -0400
>I agree that the client and server must accept the Connection: close
>header. I'm wondering how to satisfy the requirement that the client
>and server MUST include this header for the last operation in a
>sequence of operations. Specifically, how do the client and server
>know, a priori, that the current operation is the last operation in a
>sequence (and therefore MUST include the Connection: close

One way for the client to optimize its connection management is to consider
some common scenarios:

* A client implementation may choose to find out printer attributes at start
up time.
This sequence will contain just one request: get-printer-attributes
* Later on, when the user wants to print, it does:
i.e. sequence of two requests, then disconnects.
* If the user has submitted a series of print jobs, it may do:
it would not attempt to disconnect while sending individual jobs


> -Carl
>rturner@sharplabs.com on 09/09/98 02:17:29 PM
>Subject: Re: PWG IPP PRO HTTP Connection: close
>I tend to follow the saying "Be conservative in what you send, and
>liberal in whatyou accept..."Whether the text says MUST or not, IMHO
>we should be designing clients and servers to handle a "connection:
>close" header whenever it is received and still function normally,
>albeit with possibly less performance. Since I am not working on a
>client, I cannot speak for what clients are or will actually do, but I
>do think the client end should drive the connection status, whevever
> Randy

It would be more efficient if clients are conservative in keeping the
connection up too long mainly with IPP servers
running on systems with limited resources, such as low-end printer devices
whose http servers can't handle too many

>Carl Kugler wrote:
>Section 4.1, General Headers, says:
>> General Header: Connection "close" only. Both client and server
>SHOULD keep a connection for the duration of a sequence of operations.
>The client and server MUST include this header for the last operation
>in such a sequence.
>Consider the (presumably typical) case of an interactive IPP client
>with a user interface. How is the client to know when the current
>operation is the last of a sequence of user-initiated actions?
>Apparently, the only safe way to satisfy the MUST (an absolute
>requirement of the specification) would be to send "close" after each
>user-initiated action. But this would violate the SHOULD, and is
>contrary to the recommendations of "HTTP Connection Management",
>> "Authoritative knowledge that it is appropriate to close a
>connection can only come from the user. Unfortunately, that source is
>not to be trusted. First, most users don't know what a connection is,
>and having them indicate it is okay to close it is meaningless.
>Second, a user that does know what a connection is probably inherently
>greedy. Such a user would never surrender the attention that a
>connection to a server implies.
>But this is talking about the client actually closing the connection,
>not sending a header to the server to signal that the connection will
>be closed after completion of the response. Obviously, the header can
>only be sent as part of a request. Also, "HTTP Connection Management"
>says clients SHOULD close connections before servers when possible.
>How are you implementing this requirement?