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
>> 3. If the server sends a premature response, close the
> connection to the server and handle the error status as
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