You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
Reacted by mary marchini, snek, Anna Henningsen and GP
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.
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 bothhttp_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.
Reacted by Ruben Bridgewater, Fedor Indutny, Nawar Alsafar, Luigi Pinca and GP
Activity
indutny commentedon Nov 29, 2018
cc @nodejs/http
joyeecheung commentedon Nov 29, 2018
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
rvagg commentedon Nov 29, 2018
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.
addaleax commentedon Nov 30, 2018
@joyeecheung → #24739
ofrobots commentedon Nov 30, 2018
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 bothhttp_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.http: make parser choice a runtime flag
http: make parser choice a runtime flag
http: switch default parser to llhttp
http: make parser choice a runtime flag
http: make parser choice a runtime flag
http: make parser choice a runtime flag
http: make parser choice a runtime flag
http: switch default parser to llhttp
http: switch default parser to llhttp