Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring own FFI Binding for llhttp instead of using http-parser #622

Closed
Jcambass opened this issue Oct 26, 2020 · 6 comments
Closed

Bring own FFI Binding for llhttp instead of using http-parser #622

Jcambass opened this issue Oct 26, 2020 · 6 comments

Comments

@Jcambass
Copy link

Jcambass commented Oct 26, 2020

Hi there, I know there has been talk about dropping http-parser because of it's somewhat staled maintenance state. As I commented on this issue, we experienced segfaults with ruby 2.7 which forced us to dig a bit into the library and dependencies. One issue has already been fixed in ffi and the requirements have been bumped on http-parser, however we still see segfaults even with this new version.

I would love to bring http-parser back to life but even the node community seams to have given up on it:

http-parser is not actively maintained. New projects and projects looking to migrate should consider llhttp.

As stated on the llhttp repository:

Let's face it, http_parser is practically unmaintainable. Even introduction of a single new method results in a significant code churn.

Instead of continuing flogging a dead horse, we should probably invest into taking another route. One possible option would be to create a new ffi binding for llhttp. From a quick search I even found a quite recent gem that implements ruby bindings for llhttp, maybe this could be a good candidate to use in the future.

I'm sure that we can come up with some resources to work on this, but I would love to hear your opinion on this topic.

@tarcieri
Copy link
Member

I agree this has been an ongoing problem. If someone would like to prototype switching to a maintained alternative, that's certainly something we can consider.

@sandstrom
Copy link
Contributor

Maybe it would be possible to collaborate with e.g. excon or some of the other ruby http libraries on a shared http parser?

@tarcieri
Copy link
Member

tarcieri commented Feb 1, 2021

llparser is probably the most promising way forward here. See #639.

As for FFI, it looks like @bryanp has suggested it's possible to support with llhttp: bryanp/llhttp#4

@bryanp
Copy link
Contributor

bryanp commented Feb 1, 2021

Yes, it's possible. I need to find a couple of hours to finish the dual-implementation approach summarized here: bryanp/llhttp#4 (comment). Hoping to get to that in the next couple of weeks.

@bryanp
Copy link
Contributor

bryanp commented Mar 4, 2021

It took a bit longer to get to, but llhttp-ffi is published. Read more here: #639 (comment)

@ixti
Copy link
Member

ixti commented Mar 5, 2021

Thanks @bryanp!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants