Michael Sweet wrote:
>Randy Turner wrote:
> >
> > I concur with Scott's comment, and would also like to add that I
> > think the server can return an error message to a POST at the point
> > it determines there is a problem, and not necessarily when the
> > entire POST has been transferred. I think we have text in the
> > protocol doc or implementer's guide that mentions this.
>> My point is simply that 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.
>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.
> 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 at easysw.com> Printing Software for UNIX http://www.easysw.com>>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4968