Carl Kugler wrote:
>> > 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.
The point I was trying to address was this: "... the current HTTP 1.1 spec doesn't require HTTP clients to be aware of early errors, i.e. it can just see there is an error by the connection closing." While the spec doesn't REQUIRE clients to monitor connections for error status messages, it is a SHOULD. And you SHOULDN'T close (both sides of) a connection while the client is still transmitting a request, because the server TCP will generate a reset when the incoming request data hits a closed port and there's a good chance that the client will never get to see the error response, so it won't know why the connection closed and might retry a bad request.
>> > > 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.
Not necessarily: "Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation." An IPP client could have enough semantic understanding of the IPP application to realize that a Get-Printer-Attributes POST is idempotent while a Create-Job POST is not.
>> > 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.
Interestingly, the last time I checked Java's io package, closing a Socket's OutputStream (only) actually shutdown the whole connection (both sides). Making it impossible to write a really well-behaved HTTP/1.1 server in pure Java. Strange, given the close relationship between Java and HTTP. Best you can do on the server side is send the error response (with Connection: close) and hope the client is monitoring for errors and is smart enough to abort the request and close the connection.
-Carl
-----
See the original message at http://www.egroups.com/list/ipp/?start=4970