> It's not a MUST, but it is a SHOULD:
> "8.2.2 Monitoring Connections for Error Status Messages
> "An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a ?chunked? encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection.
>
> 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.
Transmitting an error response before the end of the request and then
closing the connection is not "in the middle of transmitting a response";
it is at the end of a response.
> > 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).
Any POST is by definition treated by a conforming HTTP server as not
idempotent.
> 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.
Correct - and any TCP API that prevents the server from working this way is
broken.
-- Scott Lawrence Director of R & D <lawrence@agranat.com> Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/