-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Implement HTTP client and server library #6167
Comments
I have the beginnings of a HTTP library on rust at fread2281/rust-http. I think the structure of the request/response/method/statuscode is good, but unfinished. |
@fread2281 looks promising! |
I'm also very interested in helping out with this. |
how about porting https://github.com/joyent/http-parser to Rust and build on-top some common functionality? |
@mneumann Consensus is that we want to build on the joyent parser (which is what servo uses already). Personally I don't think we need to port it to Rust, but I suppose that could be a reasonable thing to do, depending on how actively its developed. |
I contributed a bit to their HTTP parser. It's not the greatest but it does 99% of what you'd need, with reasonable efficiency and clarity of code. |
@brson is that still the plan? I remember reading servo needs something more capable. Is someone working on this? |
The situation has now changed. Servo has transitioned to my rust-http which is pure Rust code. It's far from complete at present, but is sufficiently capable at present for GET requests at least. I wish to make an important distinction, though, in what I'm doing. What's requested here is an HTTP client and server library; what I'm doing is broader: an HTTP library. The distinction I am making is that as well as providing support for acting as a regular origin server and standard user-agent, my design will sit those on top of a solid HTTP layer which will make writing things like proxy servers and gateways quite straightforward with it. |
I would suggest to close this issue as @chris-morgan's rust-http coverts the request of having a http server and client library for rust. |
I don't think it should be closed until rust-http (or some other library) has some sort of official support. Particularly given rust-http still doesn't handle things like POST and @chris-morgan keeps hinting at a big in-progress rewrite. |
In a world with Cargo, is this something we still want in the core libraries? |
I'd say no. There are more important things required in stdlib.
|
While having a libhttp might be nice, there are already too many competing third-party implementations. This has its benefits and its drawbacks, most notably that it will likely increase the amount of code duplication surrounding web stuff unless one implementation comes up as the clear winner. However, it's not something we can prevent at this point. |
I'm going to close this. As pointed out by @steveklabnik, in the post-Cargo world there doesn't seem to be much of a point to track all the nice-to-have libraries in this repository. Please feel free to reopen if you strongly disagree. |
… r=ebroto Identical arguments on assert macro family Lint when identical args are used on `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros. Added to the lint `eq_op`. Common functions added to `utils/higher.rs` Fixes: rust-lang#3574 Fixes: rust-lang#4694 changelog: Lint on identical args when calling `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros
On top of the new I/O subsystem (#4248) build an easy to use HTTP client and server library. I want to demo something very simple to use like Go's HTTP library. Needs a lot of research still to figure out what to do here.
The text was updated successfully, but these errors were encountered: