Fix attempt to read gzip content from responses that cannot contain content

[seedifferently]

Colly currently returns an EOF error on responses that contain a Content-Encoding: gzip header, but no body content.

This happens due to the initialization of the gzip reader here attempting to parse gzip header data from the response body, even though the body is empty.

RFC 9110 section 15 states that 1xx, 204, and 304 responses cannot contain content. However, some servers will still send a Content-Encoding header.

This is my best guess at how to instruct colly not to reach for the gzip reader in these scenarios (the non-gzip reader gracefully handles empty bodies).

[WGH-]

I think my #746 solves it in more general case. The problem is the PR got stalled on review, as I can't self-approve and merge

[seedifferently]

@WGH- thanks, I had not seen that PR. However, if you copy my test case over there you will see it fail because the Peek() still returns an EOF, so some additional checking might be needed to determine if the EOF is OK to ignore and move on from.

[WGH-]

That's a good catch. I'll update my PR, and credit you.

[seedifferently]

Thanks @WGH-.
Closing this in favor of #746.