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
Initial implementation for llparser binding #639
Initial implementation for llparser binding #639
Conversation
7317b91
to
69cebd8
Compare
69cebd8
to
d767ac8
Compare
Digging further into this, I am not sure if the test is correct.
So, if I were to interpret it verbatim, I would not raise an error there; even if the chunked transfer seems unfinished, the closing connection should precede it in this case. |
Related issue: #424 |
@midnight-wonderer What compilation issues did you hit with |
The llhttp gem just shipped with So an auto-deployed ruby project can't have the gem as the dependency yet. |
@midnight-wonderer It shouldn't include
Please open an issue at https://github.com/metabahn/llhttp if you want to discuss the issues you're hitting. |
Just to chime in here, I think moving to https://github.com/metabahn/llhttp sound great, but I think it'd be a lot more painless if the C extension shipped the source code as opposed to requiring a .so native dependency be installed on target systems or else installation fails. Shipping the source code with the gem doesn't preclude dynamic linking for those who prefer it: it can still link with a dynamic library if detected. But failing to install at all without a dynamic library present is a bad user experience, IMO. |
@tarcieri I agree with you, but |
Aah, great! So it sounds like the installation issues are a bug? |
Yeah, it seems that way. I haven't been able to reproduce so hopefully @midnight-wonderer can provide more details. |
Another thing to consider is JRuby. Given https://github.com/metabahn/llhttp is written as an MRI C extension, we'd need to disable it on JRuby, but then the question is what to use instead. Perhaps we could include a pure Ruby alternative parser, or find a Java parser with a JRuby extension. FFI would allow for using a common native extension on both platforms, which certainly simplifies things as there's only one parser to worry about. |
I'm certainly open to moving Btw it turns out I can reproduce @midnight-wonderer's issue. Requiring
I'll dig in later to see what's going on. |
I took a couple of hours to reimplement |
👍 for the move to llhttp, but as @tarcieri said we should ensure we support jRuby as well. Thus if llhttp will use ffi - that will be awesome! |
I just pushed a new release of Please let me know how I can help bring this across the finish line—happy to support the effort. |
@bryanp perhaps you could make a new PR? (unless @midnight-wonderer wants to update this one) |
#651 was merged to master. Huge thanks to everyone involved! |
Hello,
And ping #604, #630, #622.
I tried hooking the llparser in; it is actually not that hard.
I almost got every test passed; only one failed.
The test that failed is in
client_spec.rb
. The context is: "with broken body (too early closed connection)".The failure seems to be related to the error raised in the old
parser.rb
inadd
method.I have no idea how this thing works, maybe a leaky abstraction?
On the implementation details
I used https://github.com/metabahn/llhttp, which is not quite production-ready.
The gem did not handle the compilation properly and required some patch to work with
http.rb
.The patch in question is minimal, just:
and
For testing, you have to compile the extension manually after patching.
In summary, replacing the gem should not take that long, and this PR can be a starting point.