fix byte count returned by httpPeek for content-encoded data

[tanjiroK-coder]

httpPeek decompresses into the caller's buffer through a copy of the inflate stream, made with inflateCopy so that a peek doesn't consume the pending input, but the byte count it returns is still read off http->stream rather than the copy that inflate actually wrote through. The original's avail_out is never set for the gunzip/inflate direction, since http_content_coding_start callocs the z_stream and inflateInit2 leaves that field alone, and otherwise holds a stale leftover from the previous httpRead, so the count comes back as the clamped length instead of the number of bytes produced. On a Content-Encoding: gzip response that means the caller is told it peeked the compressed length and treats the tail of its own buffer as body data. I noticed it reading the two gunzip paths side by side: httpRead sets avail_out on the stream it inflates with and reads it back off the same one, while httpPeek sets it on stream and reads it off http->stream. Against a 13-byte body served as 33 bytes of gzip, httpPeek returned 33 with the trailing 20 bytes of the buffer untouched; it returns 13 with this change, and deflate behaves the same way. ippeveprinter happens to zero its auto-type header first so it only gets a wrong count back, but a caller that doesn't is reading uninitialised memory.

Assisted-by: Claude:claude-opus-5 [Claude Code]

[michaelrsweet]

So you missed the debug printf above this, but I'll go ahead and make the change here and in CUPS 2.x.

[michaelrsweet]

[master 6572ca6] Fix httpPeek for compressed message bodies (Issue #175)