@indutny I think that's the wrong link for the "Fixes:" part of the commit message?

CI: https://ci.nodejs.org/job/node-test-pull-request/38057/

Thanks! That was a typo in "Fix". Fixed now! 😂

CI: https://ci.nodejs.org/job/node-test-pull-request/38058/

Needs backports to all release branches. I've made 4.0.1 release to facilitate with that.

I take this statement to mean we'd need manual backports for the LTS releases (14/12)? Unfortunately it looks like the way we applied security patches hasn't kept the llhttp files in-step -- current versions of

• https://github.com/nodejs/node/blob/v14.x-staging/deps/llhttp/include/llhttp.h
• https://github.com/nodejs/node/blob/v12.x-staging/deps/llhttp/include/llhttp.h

declare llhttp 2.1.3 and is what you get in node -p process.versions.llhttp.

On master, we jumped directly from v2.1.3 to v5.1.0 in #38146

@richardlau asking the right question! I don't expect any problems with making 2.x release for these branches. Thankfully the fix is not in llhttp itself, but rather in its compiler. 2.x uses llparse@7.1.0 and the fixed version is llparse@7.1.1. Should be as easy as bumping the dependency and making a release. If there are any security fixes - I'll happily apply them as well.

CI: https://ci.nodejs.org/job/node-test-pull-request/38121/

Landed in d798de1, thank you!

Coming back to this for v14.x and v12.x. I could do with some help here working out what is landable on those re. llhttp. As mentioned before (#38665 (comment)) they both claim to be llhttp 2.1.3 although e.g. on v14.x there was a security patch applied which I think corresponded to a semver major llhttp (3?)

$ git log --oneline deps/llhttp/
641f786bb1 http: unset `F_CHUNKED` on new `Transfer-Encoding`
85062b3aad deps: update llhttp to 2.1.3
...

I guess we missed a step somewhere with the security patches and synching llhttp versions.

Perhaps the best thing to do is mark this as requiring manual backports.