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.
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.
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).
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com