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

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

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

Carl Kugler kugler at us.ibm.com
Wed Sep 30 15:27:18 EDT 1998


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/



More information about the Ipp mailing list