Handling of empty responses when dealing with GZip

[czardoz]

This is a continuation of the discussion in #2176

Basically, what should request do when a server returns an empty response with the Content-Encoding header set to gzip?

[simov]

Basically zlib throws on stream write/end in cases when the compressed data is corrupted. It turns out that similar error is thrown on empty response body as well.

I'm not able to find a way to determine if the incoming response stream contains any data prior piping it to zlib. So the underlying zlib module throws and the error is being forwarded to the end user. Unfortunately at this point your only option would be to swallow the error.

[czardoz]

As mentioned in RFC 7230, it seems that there are well defined conditions under which a response may have no body.

All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
   responses do not include a message body.  All other responses do
   include a message body, although the body might be of zero length.

and

Responses to the HEAD request method (Section 4.3.2
   of [RFC7231]) never include a message body [snip]

In these scenarios at least, can we ensure that request does not throw an error, and returns the response body as an empty string?

For example, having a 204 response to a GET is a perfectly valid scenario, and not an error. We should not forward an error to the user in this case, I think.

[simov]

All 1xx (Informational), 204 (No Content), and 304 (Not Modified)

That sounds reasonable, though as you are aware handling those status codes does not guarantee no errors.

Errors should be forwarded always, that's the point, the status code check should be placed before piping to zlib (we are on the same page).

[czardoz]

Yep, I agree with you.. request shouldn't accidentally catch legitimate errors.

[simov]

Implemented in #2176