[cups.bugs] [MOD] STR #2315: cupsDoFileRequest bug when ippRead() fails

[twaugh.redhat]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

In cupsDoFileRequest at cups/request.c:359 the 'break;' there is intended
to break out of the main loop, I think, rather than just the ippRead()
loop.  If ippRead() has returned IPP_ERROR, there is little point in just
re-sending the request in the same connection -- something more serious
has gone wrong.

I have seen this cause bad things with a CUPS-1.2.10 client trying to
print to a CUPS-1.1.x server like this:

client: POST, Expect Continue
client: IPP request
client: IPP request data
server: "HTTP/1.1 200 OK\r\nDate: [...]\r\n"
server: "Server: CUPS/1.1\r\n"
server: (other fields, then:) "Content-Length: 189\r\n"
client: POST, Expect Continue
client: IPP request
client: FIN (immediately!)

After the server has finished sending the HTTP headers, and is still yet
to send the IPP response data, the client's ippRead() function returns
IPP_ERROR because the data is not there to read.  As a result, we end up
re-sending the HTTP headers for our request!

Untested patch attached that ought to fix the problem.

Link: http://www.cups.org/str.php?L2315
Version: 1.2.8
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cups-ippRead-break.patch
URL: <https://lists.cups.org/pipermail/cups/attachments/20070329/4789d12d/attachment.ksh>