HTTP client library

[brson]

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.

[novabyte]

@brson So is the plan to add the NetScape Portable Runtime to the Rust standard library, by binding using a FFI?
If not, will a HTTP client be added to the standard library something like what's available with Go's net/http?

[metajack]

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.

[SimonSapin]

@brson, Is this still relevant after #863?

[jdm]

No real point in leaving this open. We're using rust-http and investigating new opportunities like hyper.