Implement HTTP client and server library #6167

brson opened this Issue May 2, 2013 · 14 comments


None yet
9 participants

brson commented May 2, 2013

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.

brson referenced this issue May 2, 2013


Redesign the I/O library and traits #4248

19 of 28 tasks complete

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.


brson commented May 2, 2013

@fread2281 looks promising!


steveklabnik commented May 31, 2013

I'm also very interested in helping out with this.


mneumann commented May 31, 2013

how about porting to Rust and build on-top some common functionality?


brson commented Jul 22, 2013

@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.


cmr commented Jul 23, 2013

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?


chris-morgan commented Sep 6, 2013

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.


pzol commented Feb 10, 2014

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.


huonw commented Feb 10, 2014

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.


steveklabnik commented Aug 18, 2014

In a world with Cargo, is this something we still want in the core libraries?


pzol commented Aug 18, 2014

I'd say no. There are more important things required in stdlib.

On 18 sie 2014, at 20:39, Steve Klabnik wrote:

In a world with Cargo, is this something we still want in the core libraries?

Reply to this email directly or view it on GitHub.


reem commented Aug 18, 2014

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.


ghost commented Nov 10, 2014

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.

ghost closed this Nov 10, 2014

Unknown referenced this issue Nov 10, 2014


QuickCheck port for Rust #7232

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment