Brian R. Glass wrote:
> 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 at tek.com Wilsonville, OR 97070-1000
>http://www.tek.com/Color_Printers (503) 685-2456
> =============================================================
>>
There are really two issues here. I think we all agree that it's a good idea for the client to listen for responses while sending the body of the request.
The other issue regards whether we should allow the client to expect a response from the server after sending only the HTTP header. Here's a scenario: say the client has a 25MB Postscript file to send over a slow link to a server that probably requires authentication. There is a good chance that, based on the HTTP headers alone, the server will reject the request with 401 Unauthorized and a challenge header. Or maybe a redirect to another address. In this case the client might use an Expect: header to indicate that it will wait for a response before sending the request body.
This was discussed a long time ago by Scott Lawrence in:
http://www.egroups.com/list/ipp/mg746712087.html
There is some overlap between these issues. If the client is capable of listening while transmitting, it probably shouldn't wait for a 100-Continue; just start transmitting and quit if 401 comes back.
-Carl
-----
See the original message at http://www.egroups.com/list/ipp/?start=4535
--
Free e-mail group hosting at http://www.eGroups.com/