IPP> IPP server behavior

IPP> IPP server behavior

IPP> IPP server behavior

Carl Kugler kugler at us.ibm.com
Mon Dec 14 18:06:26 EST 1998


Michael Sweet wrote:
> Carl Kugler wrote:
> > ...
> > for user confirmation. The automatic retry SHOULD NOT be repeated if
> > the second sequence of requests fails.
> > 
> > I would think that IPP POSTs, in general, are non-idempotent, which
> > would imply that they should not be automatically retried (in
> > general).
> 
> I'm not disagreeing with you here; my point is that our IPP servers
> must be able to handle broken or limited clients, and that we need
> to make sure that the *reason* a POST failed is clear to the client.
> [because the convention network printer "wisdom" is to retry until
> you know the printer won't take the job]
> 
> I'm not sure what the current implementer's guide says, but our CUPS
> client software will do the following:
> 
>     1. If the connection is refused, retry at regular intervals
>        until it can be established.
> 
>     2. If the connection is terminated during a request without a
>        response then the server has a permanent error with this
>        job.
> 
>     3. If the server sends a premature response, close the
>        connection to the server and handle the error status as
>        needed.

I'm not sure what you mean by "premature response", but the client certainly needs to be prepared to accept responses prior to completion of transmission of the request.  IPP recommends sending a response (failure OR success) as soon the request attributes have been processed (without waiting for document data).

Also "[An HTTP/1.1] client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message."  

> 
> Basically, I'm planning on seeing broken IPP servers and/or clients
> and don't want *our* software to break because of it.
> 
> > ...
> > I don't see why keeping the connection open means that you can't
> > send the error response until after all data has been received.
> > That seems inefficient to me.  Ideally you'd want to send the error
> > response ASAP to get the client to cease transmitting the body.
> > ...
> 
> Again, I'm not disagreeing here, I'm just being realistic about the
> clients that'll be out there.
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products                  mike at easysw.com
> Printing Software for UNIX                       http://www.easysw.com
> 
> 



-----
See the original message at http://www.egroups.com/list/ipp/?start=4971



More information about the Ipp mailing list