-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
HTTP client library #239
Comments
There's been some discussion of this so far, and not any resolution yet. We're investigating options for dependencies, and there is some preference for finding something that can work both for Servo and for Rust's standard library. Much of the issue is that existing implementations tend not to use IOCP on windows, but fall back to select() which is undesirable. This seems to be the case for libcurl for example. |
new test for setRequestHeader() and open()
No real point in leaving this open. We're using rust-http and investigating new opportunities like hyper. |
…ennw Preferentially dispatch events to topmost scroll layer siblings. Addresses servo#9867. r? @glennw cc @paulrouget
Silence warning on raw_pointer_derive Fixes servo#239. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/rust-mozjs/243) <!-- Reviewable:end -->
Our current HTTP library is only a stopgap solution and is poorly designed. This involves integrating a lot of different bits, including I/O and security libraries, and parsing and interpreting HTTP. We are using joyent's HTTP parser, which is suitable for servers, but not for clients that have to interoperate with decades of legacy servers.
I think we are committed to NSS for our crypto as there are only a few FIPS certified libraries and NSS is Mozilla's. NSS is going to have its own requirements, in particular it will force us to use NSPR, which may force us into a particular I/O solution.
I'm not familiar with NSPR's I/O, but presumably it has async network I/O - we definitely don't want to be wasting threads on I/O resources where we don't have to.
The best way to approach this I think is to make the NSS bindings and see what's required to make them work in Rust. Move forward from there. Let's try to keep the various components well-factored though so we have options to replace them later.
The text was updated successfully, but these errors were encountered: