Is your feature request related to a problem? Please describe.
Latest node.js can be compiled with --experimental-http-parser
flag. Eventually, we'd want to swap things around and make it enable llhttp
parser by default and hide http_parser
under --legacy-http-parser
flag.
Describe the solution you'd like
Hide http_parser
under the flag when we're ready.
Describe alternatives you've considered
No alternatives.
Let's discuss the earliest version of Node that we're going to try this in. http_parser
is a major component and it would take a lot of testing to make sure that llhttp
is on the par with it quality-wise.
cc @nodejs/release @nodejs/lts
cc @nodejs/http
Is it possible to make it a runtime switch first? My impression is that it should be possible with some small C++ refactoring in the Parser class and make the decision when we get it from the binding based on the CLI option which should be available at that point
related: I'm working on a sharedlibs builder in CI that'll test llhttp builds on all 11+ CI runs, so we'll soon be essentially mandating stability and quality for llhttp in parallel. Only covers one platform of course.
@joyeecheung → https://github.com/nodejs/node/pull/24739
IMHO, we should make llhttp
the default in Node 12. If we do not do so, we will have to maintain and fix security issues in _both_ http_parser
and llhttp
until 12 goes EOL in April 2022 at the earliest.
We will have 6 months of ecosystem testing available to us to harden llhttp
before 12 goes LTS.
Most helpful comment
IMHO, we should make
llhttp
the default in Node 12. If we do not do so, we will have to maintain and fix security issues in _both_http_parser
andllhttp
until 12 goes EOL in April 2022 at the earliest.We will have 6 months of ecosystem testing available to us to harden
llhttp
before 12 goes LTS.