IPP Mail Archive: Re: IPP> IPP server behavior

Re: IPP> IPP server behavior

Carl Kugler (kugler@us.ibm.com)
14 Dec 1998 23:06:26 -0000

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@easysw.com
> Printing Software for UNIX http://www.easysw.com
>
>

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