search

grantila / fetch-h2

HTTP/1+2 Fetch API client for Node.js
MIT License
336 stars 16 forks source link

Crash when dealing with incomplete compressed response #44

Closed triblondon closed 5 years ago

triblondon commented 5 years ago 
events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: unexpected end of file
    at Zlib.zlibOnError [as onerror] (zlib.js:155:17)
Emitted 'error' event at:
    at Zlib.zlibOnError [as onerror] (zlib.js:158:8)

Reproduces when fetch-h2 is handing a response that has Content-Encoding: gzip and is an incomplete response (eg if the request contains a Range: 0-0 header).

An obvious solution seems to be to handle the error event on the decoder stream, but looking at response.ts, I'm not totally sure how to do this, given that the contentDecoders param may inject decoders into the function, which doesn't seem to give an obvious place to set up an error handler.

triblondon commented 5 years ago

Ah, of course I can (and should) catch this in application code. Ignore me.

grantila commented 5 years ago

No worries @triblondon, yes you should catch the possible rejection from response .readable(), .text() etc. gzip and ranges sounds scary, I'm not sure what the common way is to solve it.

If you really need to manually handle incomplete data, you can make your own custom decoder and call it gzip. This will overwrite the built-in one. Yours can simply forward the raw compressed stream, and then you can manually glue the pieces together and finally decode. But it sounds clumsy.