nodejs

http-parser

C2012–2021

nodejs / http-parser · Archived

http-parser

http request/response parser for c

Explore on GitHub Read Hacker News discussions

10Distinct people

15Mentions

0Explicit recommenders

6.4KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

http request/response parser for c

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2012-01-03 19:04:45 UTC to 2021-12-09 20:22:38 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2012	2012-01-01 00:00:00 UTC	2013-01-01 00:00:00 UTC	2	2
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	3	3
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	4	4
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	0	0
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	1	1
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	4	4

What Hacker News says

15 sources

tgraf·Dec 9, 2021

It looks not too different from the majority of HTTP parsers out there written in C. Here is an example of NodeJS [0]. [0] https://github.com/nodejs/http-parser/blob/main/http_parser....

In eBPF will help solve service mesh by getting rid of sidecars

jaffathecake·Oct 15, 2021

Whoa, I didn't know that! But yeah, it seems like https://github.com/nodejs/http-parser is based on nginx. It now uses https://github.com/nodejs/llhttp but has some of the same legacy. On the other hand, deno's HTTP stuff is built on top of Hyper, a Rust library https://github.com/hyperium/hyper

In How to win at CORS

nly·Apr 19, 2021

Boost.Beast has its own HTTP parser[0], during the development of which Vinnie Falco (the principle author of Beast) found many bugs/inconsistencies in Node.js's own parser[1]. Personally I'd rather use this than something based on Node.js http-parser. [0] https://www.boost.org/doc/libs/develop/libs/beast/doc/html/b... [1] https://github.com/nodejs/http-parser/issues?q=is%3Aissue+au...

In A Universal I/O Abstraction for C++ (2020)

nly·Feb 25, 2021

Legacy HTTP/1.1 suffers a few issues, see the current RFC errata: https://www.rfc-editor.org/errata_search.php?rfc=7230&rec_st... There are issues particularly around how whitespace and obsolete line folding should be handled Various whitespace issues in node.js: https://github.com/nodejs/http-parser/issues?q=is%3Aissue+wh... Spec clarification: https://github.com/httpwg/http-core/issues/53 Node.js's parser was at one point replacing all white space in headers with a single space character, even though until recently this was non-conformant (you were only supposed to do so with obs-fold). It did this so it didn't have to buffer characters (since http-parser is a streaming parser). It's not as trivial as a few string splits. Node.js's parser is ~2,500 lines of C code.

In Plain Text Protocols

thamer·Oct 25, 2020

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules? In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components. One good example of this is node's http-parser[1] that was extracted to a self-contained C file with associated headers and is a pleasure to use. [1] https://github.com/nodejs/http-parser

In A small but complete JavaScript engine

erichocean·Mar 25, 2016

> What I think is needed is mainly a library for parsing and encoding of HTTP requests and responses (I don't know what there is for C/C++) https://github.com/nodejs/http-parser On the parser side, that's about as widely used/polished as you could hope to see.

In Silicon: C++14 web framework

nly·Oct 12, 2014

Much of the advantage of using a DFA generator like Ragel is lost because the HTTP header grammar is actually ambiguous in several places and can't be streamed. You can use it as a component, but it isn't entirely sufficient on its own. The HTTP 1.1 RFC requires whitespace be stripped at the end of header values, yet also permits (although deprecates) header folding, giving rise to the following ambiguity (using _'s in place of leading spaces): Foo: Hello\r\n ______\r\n ________\r\n ________ world!\r\n Bar: smeg This requires that the parser buffer all the whitespace between 'Hello' and 'world!' (and the RFC doesn't put a standard limit on header value length) just in case 'world!' never comes and the value of the Foo header has to be stripped back to just "Hello" Here's a related observation from a commit[0] by the

Read the rest

Joyent guys, who wrote the streaming parser used by NodeJS: "For http-parser itself to confirm[sic] exactly would involve significant changes in order to synthesize replacement SP octets. Such changes are unlikely to be worth it to support what is an obscure and deprecated feature" Another example is parsing the Request and Status lines: GET <uri> HTTP/1.1 Technically <uri> can't contain spaces, but the RFC says you MAY accept them [RFC7230: 3.5. Message Parsing Robustness] ... which then gives rise to the possibility of <uri> containing the literal string " HTTP/1.1", and ultimately opens up bad user agents that send spaces to header injection. Resolving these ambiguities require implementing your own buffering, and dropping down to Ragels 'state charts' feature to avoid your semantic actions being munged... which leaves you to design the top level state machine yourself. [0] https://github.com/joyent/http-parser/commit/5d9c3821729b194...

In Lwan: Experimental, scalable, high performance HTTP server

stock_toaster·Apr 22, 2014

maybe not entirely hand written? source[1] [1]: https://github.com/joyent/http-parser/blob/master/LICENSE-MI...

In Space Monkey dumps Python for Go

stock_toaster·Apr 22, 2014

> (that explains why node.js is a bit faster than Go for handling HTTP requests at the moment) Pretty sure node's http parsing is handled by http-parser[1], which is written in C (originally pulled from nginx as I recall). Go's http parser is written in Go. [1]: https://github.com/joyent/http-parser

In Space Monkey dumps Python for Go

nly·Jan 18, 2014

I wouldn't go there. If I needed high level HTTP access I'd go with libcurl [0]. If I wanted a HTTP parser I'd consider Joyents http-parser library from nodejs (no dependencies at all) [1]. If I wanted a SPDY library, I'd consider spdylay (used by aria2 I think) [2]. All of these libraries are MIT licensed, well documented, and designed to be very focused libraries with very little feature-creep. For TLS: PolarSSL has worked for me, but its GPL and tends to break ABI quite a bit [3] [0] http://curl.haxx.se/ [1] https://github.com/joyent/http-parser [2] http://tatsuhiro-t.github.io/spdylay/ [3] https://polarssl.org/

In Chrome Is The New C Runtime

jacobr·Aug 20, 2013

> To make a long story short: very old versions of http_parser were based on a Ragel grammar but the handwritten version outperformed it by a significant margin, as in over 10% fewer branches taken. > Ragel is great but it can't take shortcuts like a human programmer can and once you start jumping around in your grammar, things become complicated fast (and impossible to debug.) https://github.com/joyent/http-parser/pull/156#issuecomment-...

In Node.js incorrectly parses HTTP methods

myhf·Aug 20, 2013

Or at least they were looking at fixing it 8 months ago. https://github.com/joyent/http-parser/pull/145

In Node.js incorrectly parses HTTP methods

zimbatm·May 12, 2013

That's exactly the kind of attitude I am trying to warn against. I have encountered times and times again people with that exact same attitude but I have yet to see HTTP implementation that don't get bug fixes years after their start. From my experience, even an implementation with limited scope will need at least a year to fully stabilize. Just point me to one and I'll be happy to revise my judgement. EDIT: As an example the http_parser in nodejs. It's just a small part of the whole but still had bug fixes a year after nodejs started. I don't have access to the repo right now (GH is down) but here is the source: https://github.com/joyent/http-parser

In HTTP as Imagined versus HTTP as Found

pjscott·Aug 3, 2012

If anybody wants to do this, the HTTP protocol parser from node.js is really good, and deliberately easy to embed: https://github.com/joyent/http-parser

In Python 101: An Intro to logging

pjscott·Jan 3, 2012

A look at node's HTTP parsing code, 1500 lines of hand-coded and rather pretty C, makes it clear that Ryan Dahl cares a lot about HTTP in node doing the Right Thing. https://github.com/joyent/http-parser/blob/master/http_parse... (This is also very handy for people writing HTTP servers and clients in other languages, since it's independent of node, and really fast and feature-complete.)

In All Node.js servers are vulnerable to DoS