[cups.bugs] [HIGH] STR #4065: Flaw in reading chunked HTTP responses (causes "Unable to get printer status" error)

[Edgar Fuß]

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

[STR New]

There is a flaw in the logic for reading chunked HTTP responses in
_httpPeek() and httpRead2(): in case no-one tries to read past the end of
chunked data (which is the common case with IPP because the end of data is
known from the IPP), the zero-value chunk length marking the end of chunks
(and the empty line thereafter) are never being consumed from the input
buffer.

This causes that "0" line being misinterpreted (i.e. as an HTTP Status)
upon the next request, causing all sorts of weird failures.

The most common effect known to me is this happening with the printer's
response to a Print-Job command, causing the following Get-Job-Attributes
to fail and the printer being disabled with an "Unable to get printer
status" error message.

The attached patch fixes the problem by reading the size of the next chunk
in advance at the end of httpRead2() and storing it in a new chunk_len
field of the http structure. It also factors out common code for reading
the chunk length from both _httpPeek() and httpRead2() into
_httpChunkLen() since it's needed twice in httpRead2() anyway.
[The size of the dummy string to consume the empty line at the end of the
chunk actually has to be 2 since httpGets() refuses to read even an empty
line into a one-length-string. I didn't try to fix that.]

Link: http://www.cups.org/str.php?L4065
Version: 1.5.2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http-chunk
Type: application/octet-stream
Size: 5169 bytes
Desc: not available
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20120429/3361c4d7/attachment.obj>