The main case where the code was wrong is when neither Content-Length nor Transfer-Encoding was provided on a response. In this case the response is delimited by closing the connection, but KJ previously rejected it outright. AFAICT almost no one on the whole internet relies on this anymore... almost.

Implement FD passing in Cap'n Proto. 

Fix uninitialized byte arrays in encoding-test.

Initializer lists are temporaries. The code apparently works in debug mode but fails when optimized.

Add support for url-safe base64 encoding

Fix bug in `kj::newOneWayPipe(0)`.

Fix typos spotted by @a-robinson and update test failure messages to indicate that either testing failing could be due to OS SCM_RIGHTS truncation bug.

According to David Klempner, this turns out not to be a safe assumption:

https://twitter.com/CaptainSegfault/status/1112622245531144194

Interestingly, it turns out this optimization was also blocking the delivery of certain errors, because we would skip the read() where that error would otherwise be delivered. (Hence the unit test update.)

An endpoint (subclass of `Capability::Server`) may override `kj::Maybe<int> getFd()` to expose an underlying file descriptor.

A remote client may use `Capability::Client::getFd()` on the endpoint's capability to get that FD.

The client and server must explicitly opt into FD passing by passing a max-FDs-per-message limit to TwoPartyVatNetwork and using Unix sockets as the transport. Nothing other than that is needed.

Fulfill AsyncPipe::tryPumpFrom() on EOF

Previously if the input stream being pumped from encountered an EOF while the other side of the pipe was being pumped elsewhere, we did not fulfill the tryPumpFrom() promise, leaving it hanging.

This is just the protocol change, not implementation.

Previously, FDs could only be sent separately from data, with the underlying implementation actually sending a dummy one-byte message.

For Cap'n Proto FD passing, it's better if we can attach the FDs to the RPC message they arrived with, because it avoids the need to pre-negotiate where FD passing is supported: if the sender sends FDs but the recipient doesn't arrange to receive them, the FDs will be discarded and closed automatically by the OS. Whereas, if we are sending separate one-byte messages, the recipient needs to know what to do with those.

This is redundant as the destructor already uses a recoverable assertion, which will not throw during unwind.

I have long assumed AutoCloseFd wrapped only an integer and was shocked to realize it was more that that...

Fix #800 : pwritev() missing before Android API Level 24.

Update link to @popham plugin

Fix typo

Add HttpClient wrapper for limiting concurrent connections

Feature grab bag

Not sure how this slipped by for so long!

This class lets you hold a temporary value that is only safe to access under lock, while you release the lock to do some other work.