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
llhttpthe default in Node 12. If we do not do so, we will have to maintain and fix security issues in _both_http_parserandllhttpuntil 12 goes EOL in April 2022 at the earliest.We will have 6 months of ecosystem testing available to us to harden
llhttpbefore 12 goes LTS.