IPP> IPP server behavior

IPP> IPP server behavior

IPP> IPP server behavior

Michael Sweet mike at easysw.com
Mon Dec 14 16:37:24 EST 1998

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

    3. If the server sends a premature response, close the
       connection to the server and handle the error status as

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

More information about the Ipp mailing list