Also:
"Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
> Traditionally printing systems will retry network connections that
> fail, so using the "close connection on error" method could cause
> problems with clients that retry but don't check for an early
> response from the server.
>
Here's what the HTTP spec says:
"[HTTP 1.1] clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute 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).
> Yes, this is a client "implementation problem", however we need to
> make sure our IPP servers are robust enough to work with clients
> like this.
>
> For our CUPS implementation we are keeping the connection open and
> discarding data once the request gets too large. This means that
> the error response won't be sent until after all data has been
> received, however it should work with any client (even the poor ones).
>
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.
The important thing is to make sure that the client gets a chance to read the response. The server must not close it's input connection while the client is still transmitting a request. If the client continues sending data to the server after the close, the server’s TCP stack will send a reset packet to the client, which may erase the client’s unacknowledged input buffers before they can be read and interpreted by the HTTP application. However, the server can generate an error response and close its output side of the connection while the client is still transmitting a request. And seeing this should cause the client to cease transmitting the body and close the other side of the connection. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
-Carl
> --
> ______________________________________________________________________
> 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=4968