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.

std::initializer_list is problematic because it insists that its elements be const, meaning among other things that you can't move from them. So, an std::initializer_list<kj::String> is often useless. With kj::arr you can do like:

    kj::Array<String> = kj::arr(kj::mv(string1), kj::mv(string2));

This requires C++17 due to the fold expression. This could maybe be worked around using some ugly recursion but I'm writing C++17 these days so meh.

I'm increasingly thinking that maybe kj::Array itself should support Vector semantics, but for now this change makes it easier to write code that uses Vector instead of Array.

Actually add URL library to makefiles

Add URL parsing library to libkj-http

This work-around had been removed in 75c7aaee.

However, it turns out that many Debian Jessie systems still use 4.9.2 (not 4.9.4, which is fixed).

I've changed the #if to more specifically target 4.9.x, which should cover all affected versions (in addition to some fixed versions).

This uncovered some bugs and revealed that there was no way to read the Content-Length of a HEAD response. Fixed.

Although contrary to conventions, it's surprisingly easy to write code that calls connect() and then drops the address before the connection completes, and such code works with the default network implementation, so let's accept it.

Add KJ utility functions to encode/decode blobs in common formats.

- Rename UtfResult -> EncodingResult
- Make it usable like a Maybe, so that we don't need separate "try" functions.
- Check errors in hex decoding and URI decoding.

In particular: UTF-{8,16,32}, Hex, URI encoding, and Base64

This conversion would end up including the NUL terminator in the array, which is almost never what you want.

We can perhaps re-enable this in the future and have it automatically remove the NUL terminator, but we should do at least one release with it disabled to catch anyone who might be affected by the change in behavior.

People see files named "md5" and get worried about security issues, even though we're using it only as a *non-cryptographic* PRNG. So, I renamed the files to type-id.*, encapsulated the code better to make clear that it's only used to generate type IDs, and added comments clarifying that we're not expecting it to be collision-proof.

Fixes #482.

Using the `Provide` message's question ID to identify the provision doesn't work because the question ID could be freed up and re-assigned before the recipient tries to receive the provision.

We'll need to update the configure script to check for OpenSSL and conditionally build this. Ekam users will need to add -DKJ_HAS_OPENSSL to their CXXFLAGS if they've arranged to link against the correct libs.