This leaks due to the old compiler bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
http://llvm.org/bugs/show_bug.cgi?id=12286

Previously we only closed immediately after a response finished.

If recvData is empty, recvData.begin() is a null pointer and binding a Header reference to it is invalid.

Detected by -fsanitize=null.

We don't support any extensions currently, but it's important that when acting as a proxy, we don't pass through this header, since it could result in the client and server negotiating extensions that the proxy doesn't understand and will botch.

This is definitely wrong, because it makes the read/write tasks impossible to cancel and possibly makes them outlive the buffers they are reading from / writing to.

I have no idea why I wrote the code this way, TBQH.

(Or if it didn't send the entire request body.)

There are actually two new client types:
- One which always connects to a given NetworkAddress, but will automatically manage a pool of reusable connections.
- One which looks up the remote address based on the URL it is given, and manages a pool of connections for each host.

The latter of these two is a "true HTTP client library".

Use case for me is Cloudflare's "Authenticated Origin Pulls", in which Cloudflare authenticates itself to the origin server using client certificates. Thus the origin server can ensure that it only accepts traffic through Cloudflare, without resorting to IP whitelists.

This really is more of a data structure than a resource type, and it's useful to be able to share it between threads and whatnot.

The proxying code was responding to a `Close` message by ending the pump loop, which had the effect of immediately dropping the connection after a `Close` had been seen in each direction. This is arguably incorrect behavior: for proxying purposes, `Close` messages and underlying TCP disconnects should be treated as independent events, forwarded separately.

In practice this "bug" probably would never cause a problem and perhaps doesn't even violate spec (since `Close` was seen in both directions). But, OSX's implementation of shutdown() returns ENOTCONN if the connection has already been disconnected from the remote end. This is the case here, as the proxy dropped all connections immediately after sending the final `Close`.

This in turn led to a unit test failure.

The intended behavior was that the proxy would forward exactly what it saw: If a `Close` was sent, it would be forwarded, without changing the underlying connection state. If a TCP disconnect was detected, it would be "forwarded" by disconnecting the next leg. This change implements that behavior.

Due to differences in the way I/O events are queued on Windows, the timing of this test end up different, such that the two incoming pings are not both received before the large outgoing message is sent.

To fix this, I removed the dependency on native I/O altogether by implementing an in-memory pipe that does no buffering (it requires a read() and write() to rendezvous, then copies between their buffers).

Still need to add handshake separately.

It turns out that, quite often, the write() will have already completed before the method returns, hence dropping the returned promise won't cause any apparent problem -- until you try to write() a sufficiently large value that it doesn't complete on the first call. Then, you get mysterious bugs.

Indeed, it turns out the HTTP library has such bugs, which are fixed in this change.