HEAD requests cause "unexpected end of file" from gzip decoder

[colinbendell]

It appears HEAD requests cause the gzip decoder to throw an 'unexpected end of file' error. This is likely because the HEAD has a Content-Length but no body frame.

[grantila]

Is this on HTTP 2?

[colinbendell]

yes. HEAD requests don't have a body, but it appears the use of stream.pipe() in the StreamResponse() constructor. However, when the h2stream is completed, the stream pipe is closed. However, because there is a content-length header from the head response, the Response.setBody() function assumes that there is more stream to decode thus tripping over zlib's internal problems of being able to handle the broken chunks without resorting to createGunzip({ finishFlush: zlib.Z_SYNC_FLUSH }). (see: https://github.com/nodejs/node/blob/e66a2acc4cb9fc09fc32d1833b89ae56468a0931/src/node_zlib.cc#L874 )

There are a few solutions as I see it:

• use the createGunzip({ finishFlush: zlib.Z_SYNC_FLUSH }) so that we supress errors related to truncated gzip streams. the only major side effect is if the user was expected a gzip error on a partial stream
• add special case for HEAD responses in fetch-http* to pass a null stream in the constructor and add a null test to handleEncoding(). This is a bit of hack since there are other scenarios where you could expect an empty body stream such as OPTIONS, PROPFIND and theoretically 304 Not Modified (though it might depend on your position about header metadata vs. cacheable metadata headers)
• alternatively add a test on the stream.readable.length. This will be 0 at the time of the constructor, but it is very possibly misleading / racy since the stream buffer might not have been flushed yet
• simply catch the gzip.on('error') and eat the thrown error. This is probably the least desirable since it potentially ignores other errors.

With this in mind, I might suggest adding the createGunzip({ finishFlush: zlib.Z_SYNC_FLUSH }) since this has the least adverse effects and is probably more future proof.

[pseudosavant]

I am experiencing this issue as well. Was there any decision on the path forward for a fix? I'd gladly write it up and send a pull request but I want to make sure I don't go down a dead end.

[colinbendell]

I have a PR for this here: #72