>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
>header)?
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:
validate-job
print-job
i.e. sequence of two requests, then disconnects.
* If the user has submitted a series of print jobs, it may do:
validate-job
print-job
validate-job
print-job
etc.
it would not attempt to disconnect while sending individual jobs
Peter
>
> -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
>possible.
>
> Randy
Yes.
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
connections.
>
>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",
>http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt
>
>Quoting:
>> "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?