Gil Pedersen

Note that this is a bug fix to clarify the public API and make the code match this. It might however cause problems for code that uses `onRequest` extensions that...

Side issue: The CI doesn't actually test on node 18, *even though it is the only fully supported node release!* I don't know why the macOS tests fail. They fine...

Right you are @Marsup. I don't know why I wanted the extra destroys… They are gone now.

Interesting. Maybe hapi doesn't properly clean up? Though it could also be a subtle node.js bug.

Thanks. I can confirm the Chrome?? specific issue on my macOS machine using node 19. I bit of investigation with Wireshark show that Chrome opens an extra connection to the...

Further investigation into the node.js internals shows that it is the parser that somehow thinks that an initial request on a socket starts when the connection is opened, and not...

I found [a likely culprit](https://github.com/nodejs/node/blob/d3b0a2a68b5cb03de1f254cefa46f4c4023b1f89/src/node_http_parser.cc#L654-L657), originally introduced in https://github.com/nodejs/node/commit/df08d527c2083b852d8456b88b39114f30525236. While the patch also applies to node 16, the effect is only seen on v18+ since this is when the [`server.requestTimeout`](https://nodejs.org/api/http.html#serverrequesttimeout)...

You should be able to get the old behaviour by setting `server.listener.requestTimeout = 0` once it is listening. For a more long term solution, I expect that hapi should detect...

This sounds like a documentation issue. The node default timeout for http [server.timeout](https://nodejs.org/api/http.html#servertimeout) was changed in v13.0.0 to never timeout, according to the history entry.

This needs more context to properly diagnose, but it seems like you expect one or more part names to be parsed as a query param field? Hapi does not support...