IPP Mail Archive: Re: IPP> PRO> Requirements on use of HTTP/1.1 in IPP

Re: IPP> PRO> Requirements on use of HTTP/1.1 in IPP

Brian R Glass (briangl@pogo.WV.TEK.COM)
Tue, 29 Sep 1998 10:03:47 -0700

Carl Kugler wrote:
>PRO> "A client MUST NOT expect a response from an IPP server until after the
>client has sent the entire response. But a client MAY listen for an error
>response that an IPP server MAY send before it receives all the data. In this
>case a client, if chunking the data, can send a premature zero-length chunk to
>end the request before sending all the data. If the request is blocked for some
>reason, a client MAY determine the reason by opening another connection to
>query the server."
>The ietf-http-v11-spec says that the client MAY expect a response from an HTTP
>server before the client has sent the entire request, IF it announces this
>intention with the "Expect: 100-Continue" HTTP header. "The purpose of the
>100 (Continue) status (see section 10.1.1) is to allow an end-client that is
>sending a request message with a request body to determine if the origin server
>is willing to accept the request (based on the request headers) before the
>client sends the request body. In some cases, it might either be inappropriate or
>highly inefficient for the client to send the body if the server will reject
>the message without looking at the body." I don't see why IPP should prohibit
>this.

I agree. In fact, we may want to suggest that clients SHOULD
be listening to the port while sending the body of the request.
This would be usefull if the job gets canceled while transmitting
the body, say by an administrator. If the printer implementation
quits pulling data off of the network and sends the response, the
client may appear to be 'hung' until all the data is sent. In
fact, this was the behavior I noticed from some clients I saw at
the Bake Off. The cleanest way to handle this is for the printer
implementation to send a reply that the job was canceled (through
job-status?) and then let the client close down the connection.
If the client does not close down the connection then the server
should time out and reset the connection. If this happens then
the client may loose the response from the server. Thoughts
anyone?

regards,

Brian

-- 
=============================================================
Brian R. Glass                                 Tektronix, Inc
                                             26600 SW Parkway
Color Printing & Imaging Division                 PO Box 1000
                                                    MS 60-368
mailto:Brian.Glass@tek.com         Wilsonville, OR 97070-1000
http://www.tek.com/Color_Printers              (503) 685-2456
=============================================================