[cups.bugs] [HIGH] STR #1719: IPP 1-second timeout causing connection errors on congested network

[Carey Evans]

[STR New]

This bug is similar to STR #377, but related to the IPP server, not the
client.

We're running some PCs with Debian GNU/Linux 3.1 and CUPS 1.1.23 in remote
locations over rather slow and busy WAN connections.  The client is
running OS/400 V5R2 with the latest fixes applied, which uses chunked
encoding on IPP connections.

On these links, with frequent print jobs being sent, it's not unusual for
the TCP packet containing the chunk length of the IPP attributes or a
block of print data to be dropped, and eventually resent, but after more
than a second.  In this case, the call to httpWait(1000) in ipp_read_http
will have returned with no data received.

Depending on when this occurs, CUPS will either send an immediate 400 Bad
Request response, or it will queue all the data received so far to the
printer and send a 200 OK, then a 400 Bad Request when the subsequent
print data isn't an HTTP request.

It would help if CUPS noticed that it hadn't received the final chunk and
logged a message to that effect before closing the connection, instead of
successfully queueing the partial printout.

I've compiled a version of CUPS with a much longer timeout, which
shouldn't cause any problems since the OS/400 machine is the only client,
and I'll update this bug when I've had a chance to try it out.

I've attached an extract from the log file with identifying features filed
off.

Link: http://www.cups.org/str.php?L1719
Version: 1.1.23
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error_log
Type: application/octet-stream
Size: 3574 bytes
Desc: not available
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20060523/9576f275/attachment.obj>