Open colinbendell opened 4 years ago
Is this on HTTP 2?
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:
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 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)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.
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.
I have a PR for this here: https://github.com/grantila/fetch-h2/pull/72
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.