[HIGH] STR #4065: Flaw in reading chunked HTTP responses (causes "Unable to get printer status" error)
Edgar Fu?? <ef-o02PS0xoJP/[email protected]>
| Newsgroups | gmane.comp.printing.cups.bugs |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ cups-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/cups-bugs
http-chunk
(application/octet-stream, 5 KB) - not displayed