HTTPParser becoming increasingly opaque

[jcoglan]

As of (I tihnk) v0.11.6, the API of process.binding('http_parser').HTTPParser has started using magic numbers instead of names for things.

One such change is replacing parser.onMessageComplete and friends with parser[3], although thankfully those magic numbers can be replaced with parser[HTTPParser.kOnMessageComplete].

The HTTP method yielded by these callbacks have also been replaced with numbers. I use this parser in websocket-driver and have had to include my own number->name map in my class that wraps HTTPParser in a stable API.

faye/websocket-driver-node@2dff35d

I don't know if this is intended to be a public API, but if so could it be kept more expressive and informative, and if not can you let me know what I should use instead.

[tjfontaine]

That's correct, from benchmarking it's slightly faster for us to dispatch callbacks by accessing them via a numeric index instead of by name. We consider everything under process.binding to be a private API, but are sensitive to the fact that some users have been using it. I will try and add a sensible map so you don't have to maintain that yourself, even though I strongly advise trying to not use process.binding APIs.

[jcoglan]

I appreciate that its intention is to be private, I'm using it since I'd rather lean on the Node HTTP parser than write my own, for speed and consistency reasons. If there's a good alternative in npm you can recommend I'd consider switching to that, but I think there is value in exposing Node's protocol parsers for use cases like mine.

[trevnorris]

HTTPParser is working as intended, so I'm moving this to a "feature-request".

[jasnell]

Going to close this. There is work underway to reimpl http parser in javascript in io.js.