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
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