Implement HTTP client and server library

[brson]

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.

[acertain]

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]

@fread2281 looks promising!

[steveklabnik]

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

[mneumann]

how about porting https://github.com/joyent/http-parser to Rust and build on-top some common functionality?

[brson]

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

[emberian]

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.

[acertain]

@brson is that still the plan? I remember reading servo needs something more capable. Is someone working on this?

[chris-morgan]

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]

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]

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]

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

[pzol]

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

On 18 sie 2014, at 20:39, Steve Klabnik notifications@github.com 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]

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.