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