subtext underline zlib error

[pegerto]

Support plan

is this issue currently blocking your project? no
is this issue affecting a production system? yes

Context

• node version: v16.18.0
• module version with issue: "7.0.4
• last module version without issue:
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): hapi application
• any other relevant information:

What are you trying to achieve or the steps to reproduce?

Standard hapi application currently under security scan fail decompressing invalid data.

What was the result you got?

node:events:505
      throw er; // Unhandled 'error' event
      ^

Error: Invalid compressed payload
    at Gunzip.stream.emit (node_modules/@hapi/subtext/lib/index.js:129:26)
    at Gunzip.onerror (node:internal/streams/readable:773:14)
    at Gunzip.emit (node:events:527:28)
    at Gunzip.stream.emit (node_modules/@hapi/subtext/lib/index.js:132:21)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

Killing the process

What result did you expect?

Expected to handle the request and get a 400 http code.

[pegerto]

Can this be related to #96?

[devinivy]

I've attempted to reproduce this with hapi v20 and v21, and subtext v7.0.3, v7.0.4, v7.1.0, and v8.1.0 without any luck. There are also some tests for this here, which would helpfully catch the issue. Do you happen to have any more info? For example, how is the route configured? If the route receives the raw payload stream, how does it handle it?

One way I can trigger this is to use output: 'stream' but not handle any errors from the stream in app code, which I believe would be an implementation issue on the app side.

[kanongil]

Hmm, with output: 'stream' this seems very likely.

Subtext could add its own "error" handler to the returned stream, but would have nowhere to report any issue. So the error handling is definitely the responsibility of the consumer, which is actually Hapi itself.

In hapi, there is no requirement for handlers to actually interact with the request.payload stream, so an error here should not cause it to crash. Especially since it can error before the handler is even called! Ie. hapi needs to add its own "error" handler, and apply the failAction to it.