Node.js HTTP Parser, What's Going On?  ## Metadata - Author: [[OpenJS Foundation]] - Full Title: Node.js HTTP Parser, What's Going On? - Category: #articles - Document Note: --- tags: [#nodejs, #http, #parser] - #nodejs - #http - #parser Author: Matteo Collina (speaker, Node.js contributor community) Source: YouTube - "Node.js HTTP Parser, what's going on?" Reference: [Watch on YouTube](https://www.youtube.com/watch?v=L-VONzXQ944) date created: 2025-08-24 06:30 --- # Title: Node.js HTTP Parser – Current Challenges and Future Directions ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The Node.js ecosystem transitioned from the legacy **http_parser** (C++) to **LLHTTP** (based on `llparse`), which doubled performance but introduced major **maintenance issues due to zero documentation**. Current concerns include leniency in parsing (introducing vulnerabilities), reliance on outdated standards (RFC 7230), and difficulties debugging the massive state machine architecture. The talk proposes a **Rust-based rewrite** with strict defaults, better readability, modern HTTP compliance (RFC 9110), and potential unification of HTTP/1, 2, and 3 under a consistent architecture. The long-term vision is a **new HTTP stack for Node.js**, potentially housed in a working group or modular library initiative. --- ## 📖 Main Content: The speaker maps the history and current pain points of Node’s HTTP parser, then proposes future architectural directions. The tension: performance vs. maintainability. While LLHTTP is efficient, it is **opaque, undocumented, and risky** for contributors. A rewrite in Rust offers a potential solution, but also risks fragmenting adoption. There is also a governance/organizational gap: Node lacks a dedicated HTTP working group despite the module being mission-critical. ### 🗒️ Notes - [00:00](https://www.youtube.com/watch?v=L-VONzXQ944&t=0) HTTP versions overview - HTTP/1.1 dominates public web traffic. - Internally, proxies mostly communicate via HTTP/1. - Node historically used **http_parser** (C++). - [01:00](https://www.youtube.com/watch?v=L-VONzXQ944&t=60) Legacy parser replaced - `http_parser` → hard to maintain, steep C++ learning curve. - LLHTTP introduced in Node 12 (2019). - Doubled throughput (1.5m → ~3m req/sec). - Based on `llparse` state machine generator. - [02:05](https://www.youtube.com/watch?v=L-VONzXQ944&t=125) LLHTTP issues - **Zero documentation** → contributors can’t safely modify. - Adding states risks breaking other flows. - Test suite robust but difficult to extend. - [04:08](https://www.youtube.com/watch?v=L-VONzXQ944&t=248) Leniency problems - Node accepts non-compliant requests. - Each leniency introduces vulnerabilities. - RFC 7230 used → outdated (RFC 9110 supersedes). - [06:02](https://www.youtube.com/watch?v=L-VONzXQ944&t=362) Proposal: Rust rewrite - Retain state machine architecture. - Strict by default → no silent leniency. - Transpile Rust to static libs or WASM. - Better contributor accessibility than C++. - [07:51](https://www.youtube.com/watch?v=L-VONzXQ944&t=471) Architectural unification - Aim: unified API for HTTP/1, 2, 3. - Maintain separate implementations under a common semantic API. - Inspired by Ada (URL parser rewrite). - [11:30](https://www.youtube.com/watch?v=L-VONzXQ944&t=690) Node core API redesign discussion - Students shouldn’t need Express to set basic headers. - Idea: core HTTP APIs should be **usable out-of-the-box**. - [17:52](https://www.youtube.com/watch?v=L-VONzXQ944&t=1072) Organizational questions - No Node.js HTTP working group exists. - Could live under Web Server Frameworks charter. - Consider a dedicated HTTP module team. - [24:32](https://www.youtube.com/watch?v=L-VONzXQ944&t=1472) Path forward - Step 1: ship new parser prototype in Rust. - Step 2: iterate with test coverage + modularization. - Step 3: fold into broader Node.js ecosystem. --- ## 📖 References: - [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110) - [Node.js LLHTTP GitHub](https://github.com/nodejs/llhttp) - [Node.js HTTP Parser history](https://github.com/nodejs/http-parser) - [Ada URL parser project](https://github.com/ada-url/ada) --- ## 🗣️ Paraphrase: 1. **Original**: “Every leniency rule introduces vulnerabilities and we should stop doing this.” **Paraphrase**: Allowing non-standard HTTP requests weakens security, so Node must enforce strict compliance. 2. **Original**: “Rust is low-level enough for performance but high-level enough not to scare contributors.” **Paraphrase**: Rust strikes a balance: it delivers performance like C++, but with accessibility that invites broader contributions. --- ## 📰 Newsletter: ⚡ **Node.js HTTP Parser – A Rusty Future?** Node.js’ HTTP parser journey continues: after moving from `http_parser` to LLHTTP in 2019, performance doubled, but maintainability tanked. Why? **No documentation** and a giant state machine that even core contributors fear touching. Now, the community is exploring a **Rust-based rewrite**: - 🚀 Strict compliance with RFC 9110 (goodbye leniency & vulnerabilities). - 🧩 Modular design with static libs or WebAssembly output. - 🌐 Future-proofed for HTTP/1, 2, and 3 under one semantic API. Discussions are also underway about forming a **dedicated HTTP working group**—a missing piece for Node’s most critical module. 👉 Watch the full talk: [Node.js HTTP Parser, what’s going on?](https://www.youtube.com/watch?v=L-VONzXQ944) --- ## ✅ Action Items: - Document LLHTTP internals → onboarding new contributors. - Prototype Rust parser → measure performance vs LLHTTP. - Evaluate RFC 9110 compliance & migration risks. - Propose Node.js **HTTP Working Group** charter. - Align governance with broader OSS sustainability (like OSPOs). --- ## 🧪 Hypotheses: - A Rust parser improves security and contributor accessibility. - Strict compliance reduces vulnerabilities without significant adoption loss. - Modular HTTP stack unifies APIs across versions. ### 📊 Methodology: - Benchmark Rust parser vs LLHTTP under high load. - Run fuzz tests for compliance with RFC 9110. - Contributor survey: accessibility vs C++. - Track bug discovery rate pre/post rewrite. ### ❓ Questions: - How will strict compliance affect backward compatibility? - Can Node balance raw performance with developer ergonomics? - Should Node core own this, or a modular library outside core? ### 🔮 Future Research: - Investigate WASM for parser portability. - Explore semantic layer unification across HTTP/1-3. - Study other ecosystems (Go, Rust, NGINX) for parser governance. ### 💡 Implications: - A safer, modern parser future-proofs Node’s HTTP layer. - Governance reform could make HTTP handling more resilient. - Lessons here could influence **open-source parser design globally**. --- ## 🧠 Learning Styles Assessment: - **Visual**: State machine diagrams shown → ✅. Needs more contributor-facing charts. - **Aural**: Talk format aids auditory learners → ✅. Add podcast/audio summary. - **Verbal**: Technical language clear → ✅. Could use analogies for newcomers. - **Kinesthetic**: No interactive demos → ❌. Add labs for building mini-parsers. - **Logical**: Strong algorithmic reasoning → ✅. More step-by-step breakdowns needed. - **Social**: Group Q&A present → ✅. Encourage follow-up forums. - **Solitary**: Reflection prompts missing → ❌. Suggest developer journaling tasks. - **Naturalistic**: None → ❌. Could frame parser evolution wit - Summary: The Node.js HTTP parser is a software that helps to parse and analyze HTTP traffic in Node.js servers. The current HTTP parser in use, LLHTTP, was developed by Federico Dossena in 2019 but does not have adequate documentation which makes it difficult to maintain. As a result, the author is proposing a complete rewrite of the parser using Rust, a language that is both high-level and low-level and will be faster and easier to manage. The new parser will also have stricter rules and follow the latest HTTP standard. This new parser will serve as the foundation of a new HTTP stack that will unify HTTP one, two, and three, with the goal of having a common API for all. - URL: https://www.youtube.com/watch?v=L-VONzXQ944&list=PLyspMSh4XhLO15jJD9Sj069fN18j12AbQ&index=10&ab_channel=OpenJSFoundation we all know that we have three versionof HTTP right one one one point one HTTP2 and http 3.uh I'm gonna skip the historical part ofit but for now let's just consider thatfor the 80 websiteshttp11 is still the most active and mostused protocol especially if you thinkthat those stats only analyze theoutfacing part of HTTP is only the onethat is client server but if you thinkabout internally with sort of a reverse proxy99 of the time the reverse proxy istalking to node or whatever via HTTP oroneand not even by using keep alive whichis a very stupid thing but that'sanother topicum where are we not you know we used tohave node HTTP underscore parser up to2019 it was one of the oldest dependencynode inspired by Ruby monreal and engineX and it worked just fine he was capableof delivering 1.5 million requests persecond back thenit was an amazing software the onlyproblem is thatit had a very complex architecture wasvery hard to maintainnearly impossible to maintain and it wascompletely written in C plus pluswhich of course make the learning groupvery steep I mean it's not thefriendliest language to usethat was the situation up to 2019 which means not 12. back then what happened isthat Feathering dudney wrote LL HTTPwhich is our current parserthis nuclear impulsory is just anamazing piece of art because it justworks very fine we doubled ourperformancesand we have a are easier to managesoftware because llhttp is based onllpars which is a state machine parsercapable of generating a parser for any text based languageit just have one little problem iswritten to transpile typescript to Cthat's how it worksand it is a mess because LL HTTP has nodocumentation whatsoever nothing at allso every time you have to work into thatis basically a crossing fingers andhoping that everything will just work that's an issue because when I startworking on an lhttp A couple of yearsago with some security fixesit was a nightmare especially when youswitch to the test Suitethe test rate was also amazing it has avery comprehensive test suite foranalyzing HTTP this test Suite wasiterated by HTTP parserbut it was written and purportedto transpile mark down to C so llhdp I mean feather is a genius butis a crazy genius one of those crazyGeniuses it was just amazing it worksjust fine but he left not a single lineof documentation so it's nearlyimpossible now to maintain thatthat's insane that's if you look at mylatest PR I sayI hope it works but I actually have noreal idea why and how it works and theimpact because anytime I add that newstate in the huge State machine I have no idea what's going to happen ifI'm going to introduce any side effectif you look at the original there is onYouTube online the original presentationby Federer aboutllhttp on this on a slide it showed thestate machine generated by LL parse forHTTP is like this size image full ofStates you can not even read the levelsbecause they're too smalland when it's transpiled it's actuallyautomatically generatedhuge switch statement in C and I'm talking about 100I mean a thousand or something differentstates there which is impossible todebugthat brings to the next to the simplepoint is thathow do we fix this situationnow the architecture of the architectureof lhtp is supercular that is prettymuch impossible to fix itand it also has one problem that isbecoming over time a huge problem but is also something thatis relevant to node.js in generaldue to this thingum with my first talk that I everdelivered was about how I fixed thislolores bugging node and I did it innodecon last October rightand I keep doing this talk because theyask him for this talk in manyconferencesthere is just one big problem every timeI find myself talking seeing the honest truth which is if you want to feelreally protected by this kind of DDSattacks or something like thatdon't put note directly in contact tothe clientwhich as a not contributor is weirdbecause you look at people saying oh youbrag that you're not contributive youbreak that not this cool and then youbasically tell me do not use notemakes no sense and why do we have thisproblem because we inherited by earlystage of node one approach that I think we should completely give up which isthe HTTP parser is lenientor Not by default but it can be easilymade lenient which means accept all thehorrible stuff that non-compliantclients wants to do and for for each ofthose that I accept one leniency rule Ipotentially introduce a lot ofvulnerabilities and in something weshould stop doingeven worseum but this this is not it's just thatLL parse is pretty old umllhttp is currently parsingRFC 7230 which is now also obsoleted thenew standard for HTTP HTTP is 991-10if we start supporting that in lhttpwe're potentially introducingincompatibilities because the twostandards might be in Conflict so whatdo we doI have a solution in mind that I stillwant to implement and see where it leadsme and or if I also join this thing to what we spoke today about having astandard Library modular Library aninitiative similar to undishi I'mthinking about writing a new parser forHTTP this time not in C not inJavaScript not in typescript I'm leaningtowards the rustrust is low level enough to be a goodlanguage for performance but high levelenough to not scary people if they wantto contributeI also plan to have this parser trytrying to transpile to rush itself optimize pressed but still readable by ahumanand eventually after this stagegenerate standard static libraries thatcan be linked against node like we dotodayis a new approach that I I want toexplore I haven't written a singularcode yet I've seen that I can easilygenerate a standard library and seeothers to include in two nodes so thisis doable or eventually we could ditchthe C plus plus and we directlytranspile to webassembly if it's fasterthat's also something 40 stands for um foreignand also in this one I want to keep thegoods of lhtp so I will keep the statemachine architecture I will keep thetest Suite but I want to do somethingdifferent better transpilation and alsostrict by default no leniency allowed atthe beginning if people really want thatthing eventually later we canreintroduce leniency but for now we arestrict we follow the standard by therule the latest standard so 9110 we ditched the 26 16 the 7230 we justsupport the latest oneand my this might be the first step to anew HTTP stacky node because we mighthave unified architecture with one twoand three disperser and eventually a newserver like happened to undish a newcompletely sir modern server for theHTTP stockthat's it you saved a lot of slidesit'syeah this is very cool so yeah[Music]umthere we go all right so the firstquestion that comes to mind is uh is theLL parse which is the state machinegeneratorum that you would passthings into is that piece of the puzzlefine to keep around could we no the thing is that if you analyze LL HTTPsource code you can kind of read thetypescript codeand follow the States from State a toState B because the interface is prettyclear now the things that for me wasimpossible to relate how a state ismapped to the C versionand that's LL purse which has zerodocumentation I see so you're talkingabout a uh uh just a ground up rewrite um now you mentioned keeping this I meanthis uh I've thought about this too I'vebusted open the the nine 1910 or 91 10whatever the whatever that that RFC isuh it is yeah very complexum have we considered doing somethinglikeum the node performance talk uh uhyagi's had like brought on like a like aprofessor of of computer science Ibelieve to help him rewrite the Ada parser the URL parser um which he titledAda and it uses like like uh fascinatingum algorithm parsing algorithmtechnology to like get that or could weconsider essentially Consulting someonesmarter than ourselves to be likeabsolutely like sleep machine parsingsfastis there a better algorithm that existsnowadays can we you leverage that yeahreversing algorithm instead yesabsolutely we could but I guess in the I I haven't checked out either he'swrittenum but I guess he said he has thesimilar problem that we have in HTTP isthat one very good thing aboutumumlhttp that is it uses zero pretty muchclose to zero extra memory basically yougive the input it does not need to copyany data of the input you just now let'sbyte by byte I mean character bycharacterand except for maintaining a state ofthe I mean the current state so very close to zero or memory over red it doesnot involve creating structure does nothold anything and that's something Iwould like to keep because it's veryperformant because we basically we don'tdo anything with the with the data yeahI would say I mean I would say like thisis um academically this is just talkingabout parser technology yeah yes thereare there are just go-to parsingalgorithms and parsing formats that areyeah either zero memory overhead orotherwise and it's like you pick one or the other the things that in thatparticular part of uh node we care aboutperformance because people want to havea fast I mean people are asking for moreperformance and I think they're nowthey're very supportive nowadays becausethey use there used to be a ruby railstimes right I'm I love Ruby real but itwas much slower when I discovered I knowthey say oh this is much faster and thenpeople say oh we want to be faster ohcome on come on please someone you haveto stop asking right yeah but I mean Isee your point Ethan uh if we can if we have people that can uh help me designout the fastest or the smaller algorithmI would love to have them on boardbut uh for for now to be honest at thebeginning what I'm focused on right nowif to see if I I want to have a reallylittle proof of concept to see if I canreproduce this thing and then eventuallyfine-tune performance and so forth butat least I want to see if he'sdoable to rewrite a similar architecturein Rust with all the specs that I toldyou aboutso you mentioned this being the foundation for a new HTTP stack wediscussed this uh not this part of itbut the higher level stuff in the webserver Frameworks team which I thinkmaybe at some point go through some ofthe the issues and I'll link you someum the conversations did stop a littlebit because of the HTTP 3 stuff so whatI'm interested to hear from you is howdo you seethe unification effort going on top ofthis New Foundation like do you do youhave a technical design in mind uh no not at the moment first of all I want Iin this life I promise James that we'regonna review the quick PR before we getto http 4 because it's something we haveto do at some point that the thing isthatum the problem is that those stocks arevery complex because HTTP one was textonly I'm not sure which part of HTTP 2is binary and HTTP even worse so theremight be no way to unify this thatarchitecture but at least let's say wecan come up with the common API or at least common Avi eventually orinterfaces even though theimplementation then must be differentbecause I mean it's very hard to thinkthat we can get the same architecturefrom TCP and UDP for instance I meanSpeedy versus quick or so forth but atleast we try to we start thinking aboutHTTP is a gigantic common module thathas three probably different versionrather than what we have today which wehave HTTP HTTP 2 and then even a thirdPR which makes things too muchfragmented yeah and so that was one of the problems we were really trying totackle with that discussion isespecially with the fact that the twoand three implementations are just sonot widely deployedum we were trying to figure out what isthe right line for the API that weExpose and what we landed on was we needtwolayers of API a very low level one whichis probably three separatestill HEB one two and three and a higher level one which is what we actually haveusers directly using and the users mightbe Frameworksbut ideally and this is what the reallike thing we were going for is ideallythe Frameworks are there to addstructure but the actual API that nodecourse exposes is usable for the basicuse case right so that would be likeum you know it correctly sets thecontent length yes right which is like a framework thing today right not a nodecore thing and like the idea would be aa you know college student who'slearning node is probably not going tounderstand how to set the content lengthheader properly and today the onlyanswer to them is go use express orspecify whatever what would be nicewould be if we had those things startingto move more toward the core model soI'm interested in what you think aboutthat and if you I don't know if you think about thatum if you remember we're talking aboutthe parts that I I mentioned RFC 9110right if you look at the title of thereferences HTTP semanticsso does not allow for the versionbecause the version apparently isoutside of that thing because even onthe HTTP different version they say thebottom layer is handled by threedifferent version because there ispipelining there is multiplexing thereis other thingsand on top there is semantics aboutMetal there's uh content length chunk technology and so forth so so that's sowe have two UI completely agree that wehave to think on different layers yeahand it's it's that's what I rememberreading I remember reading there's so Ijust pulled it up 1910 is semantics 1911or sorry 9110 is semantics 911 iscaching 9112 is 1.19113 is 2 91 14 is 3. yes and thenthere's like and then beyond that it's all the other ones all of the olderspecs there's like 5861 82 46 these areall like different other pieces but it'slike as as you were saying if we buildif we do1991-10 as that like core piece then youcan implement the other ones on top ofit which is a solution to what I thinkthe old the old web Frameworks group wasdiscussing is we want to if we think wewant a new HTTP stack in core I think wegotta revisit these standards yeah specifications and rebuild some thingsand followed by the rule because theproblem is that we've been allowingclients and servers to do nasty thingswhen they speak to node we stop doingthat because every time we allow for arule we mess up another rule for sureokay and so that was my follow-upquestion then if we like this directionand you're talking about doing itsimilar to indichi uh I my question ishow do we see those other layers do wethink we need to do them all in the sameway like we pull them all out in a separate repos we get them lined upfinalize them make them good and then wevendor them in and if so then do wevendor them into and there's a bigdiscussion we had that group is likewell we already have HTTP https HTTP 2HTTP 3 what do we call it right I haveno answer because the thing is thatbefore doing before coming here today myintention was I write another parser Ireplaced the dependence in an Englishdtp done so it was not meant to be astandard library but then we spoke this morning on the next 10 and say oh youknow what that might be a good example agood first or second module that use usis a is close to core supported by corebut not part of core similar ohmajorities so I kind of changed mydirection this after this morning talkand we have to see even with that effortwhere we are adding I have no answer atthe moment because if we chose not to dothat effort anymore I will go back tothe original idea that as we did forHTTP parser we replaced the dependency but at the moment I have no answerbecause when thatinitiative leads us we also lead theperson with this in this initiativeyeah I think it's probably not smart totie them too tightly together because ifyou make great progress then like thatshould just land right uh if possiblebut I think at least keeping in mindthat at some point we want to put someeffort into making a better end userHTTP experience in directly in node core is at least just like something to keepin the back of your head it's probablymy opinion isinitiative is that since we know thatwe're usually vertical and sort of evenvery grandfathering for the users thosemodules are never going to disappear andwe're just going to be a new namespaceof models that are eventually encouragedbut the other one are still supportedbecause we have to support people up to10 years from now and so forthbut I guess you could vendor everything behind a node double dot new HTTP onethat is not currently usedif we want to I mean did you rememberthe HTTP parser lhttp transition whathappened yeah the thing is that it didit was first experimental then it wasenabled by default and eventually the HDI mean actually HTTP is still there inthe source code you can eventually stilluse itafter 12 to 14 16 18 20 after fivemeasure versions still there so seven scorers at allso that's make no sense yes true but itwould be like uh everything like thetesting on or and everything like itcould allow people to build on top of ityeah if they want it yeah if no one andif people want to continue to use someframework implementation on stuff likethat I can still use it we won't bebreaking anything but it would be aneasy way to provide new stuff to peoplewithout including breaking chain and you can use it it's a specific namespacestuff inside yesum yeah yeah I I was just thinking likeif if we could like build HTTP HTTPparser as like just a parser module onits own expose that like totallyseparately from like the actual servingof things likewe kind of already have like the lowerlevel facilities like you could spin upa TCP server and then like do the manualthing if you wanted to but we could then like use that as like stepping stone toadd more things like like I I mentionedin like the next 10 thing earlier uhlike the service worker fetch event likea lot of like cloudflare and all theselike like serverless platform things aredoing that likefetch events spec thing you just havelike add event like ad event listenerFetch and like Behavior like you're aservice worker like if we like we could introduce that as like a new HTTP APIthat uses that instead in like thefuture and just like introduce all thesenew pieces on top of that but not needlike the whole thing at once[Music]umstealthy or meeting from this is that ifwe manage to do this for HTTP we canpotentially do for many other parts ofthe code yes of course let's forget itand the thing is that the only reasonwhy I want to tag this to node core a lot is becauseum at the moment the HTTP server processthe data in the C plus layer before evengetting to the JavaScript layer whichmeans that for this reason since I don'thave access to Native buildings like wewere talking this morning it's hard forme toumbe performant if I have to do from Cplus plus to JavaScript to eventually toC plus plus or webass place so I have adouble jump of the data that I have to find good way ways to avoidbut that's another topic that's at leastforthat I have to yeah I have to speakI have to speak with him about thisthat's that's the biggest issue here Idefinitely yesI would say uh definitelystay focused on that like single pieceand like yeah it's awesome ideas of whatwe can do next and all that but like wecan't we can talk about those things asmuch as we want until we build thatfirst piece until you re-implement thatparser nothing else can come so it's oneof those like just do that yes and then let's solve the next problem and let'slike cross those bridges when we get tothem we can think about them we can talkabout them but also like let's get thatlike let's ship that change soum is your ask are you looking for otherpeople to help or get involved are youleading this are you I was notspecifically asking for uh from peopleso I started I'm mostly starting nowthat as a spike because it has a spikeor POC whatever you want to name it ifpeople want to contribute are morewelcome to do so so anybody is more than welcome to contact me and we can seewhat we can do absolutely awesomethank youany questions comments whateverJean[Music]do we want to do something with a webhammock team group something to have afollow-up or it's like I don't reallycare about this one butwell so it doesn't but it is still Idon't know if it's chartered it's gotits it's got its um it is open with everything so if youneeded a host group to host the worklike there's some structure from nodearound like what a team can own okay andthen the team can like graduate to a ifyou need the actual like ownership rightthe like structures are there to thengraduate that to a working group uhwhich we decided not to do because wedidn't need it at the time but it'sthere actually this also brings to one thingin node where for some reason lacking Imean it's not because I work on thatmodule but we can probably all agreethat HTTP one two or three whatever I'mnot I don't care about the version isone one if not the most used module inHTTP and there is one no working groupfor that is so weird well so the webserver Frameworks Charter like coversI think all of this like I think so ifyou wanted that to be it like we can we can just fix it to make it more clearlywe could even change the name probablypretty easily I meanis quite just with servicewell specifically at the time thediscussion and why it started wasactually at one of these I like went toMateo and I was likeExpressify has like so much overlap and now I'mactually on the team that maintainsrestify so like I I like I I'm likeyeah so I have like I was like this is we have so much duplication of thingsthere's no good way for us to reallylike collaborate and I think we allagree that stuff needs to be moved thecore apis need to be better and so itspun out and we specifically chose webserver Frameworks because it wassupposed to be a collaboration betweenthe maintainers of the existing webserver Frameworks what came out veryearly was that the clients have a stakein this so that is how the the fetch implementation discussion got started soI think we probably have just like aslight miss when we started it withoutjust we didn't realize quite that so Ithink if we changed it to be HTTPworking group or whatever we wanted tocall itum I think that would be probably a goodwell it works fine to me absolutely fineyeah yeahthat's goodokayso when I I mean to be honest personallyspeaking I have limited time to explorethese things due to for working reason but I will try to explore as soon aspossible as soon as I have a little newsI will ping you all and eventually youcan start working on the other workinggroup and one nice cool thing is that Ithink that there's a team on GitHub setup for it so you can like app mentionthe whole team and it pings everybody sothat would be a nice way to justleverage that again that's where the theteam set up it's just like it's justlike the structure that helps it make iteasier for you to reach the right peoplecool it doesn't need to be meaningfullychanging what you're working on it or however yeahworks fine cool, Node.js HTTP Parser, What's Going On?, OpenJS Foundation, 01h3j5ztay03gzhhq3522fkbje.