Reading an unbounded amount of data from a stream is a potential DoS vector. To manage this risk, readAllText() and readAllBytes() now accept a `limit` parameter. For source backwards-compatibility, this limit defaults to kj::maxValue.

Fix a typo

s/starp/strap/

Fix chunked body gather-write test.

The braced array literals seem to be constructed as temporaries. The test passes in debug builds, but in optimized builds, the arrays have been overwritten by the time they are used.

Chunked body fixes in kj-http

The gather-write and tryPumpFrom() member functions weren't encoding their chunk sizes in hex, and the gather-write case had an off-by-n error building the body data pieces.

Allow hash signs in path and query components in kj::Url request contexts

Occasionally servers processing HTTP requests will see URLs in the wild which have unescaped hash signs in path and query components. This change allows kj::Url to parse such URLs in the Url::HTTP_REQUEST and Url::HTTP_PROXY_REQUEST contexts.

Add sychronous gzip stream implementations.

I was shocked to find that there was no good way to represent a multi-line literal currently. This implements C-style literals, where multiple consecutive string literals are concatenated.

Similar methods already exist on AsyncInputStream.

Really actually fix HttpServer::drain().

It turns out I was testing it wrong, and it still doesn't work. :(

Fix regressions in HTTP drain.

Rewrite JSON decoding

Simplifiy implementation and, as a bonus, allow overflowing floating numbers to convert to +/-Infinity like they do in JSON.parse.

Also update outdated comment about NaN and Infinity being encoded as `null`.

 - Add support for decoding with Orphanage.
 - Allow decoding of non-struct root JSON objects.
 - Add support for custom decoding type handlers.
 - Add support for custom decoding field handlers.

Add flag to kj::Url::parse() to prevent automatic decoding of URL components

I haven't looked at it in years, why waste everyone's bandwidth?

Fix problem on android api < 23

Don't log/throw exceptions if the service returned successfully witho…

Theory is that maybe it did this intentionally, e.g. because it really just wanted to disconnect and it already dealt with any errors. The client should notice the stream ending prematurely so it should be possible for the developer to see the problem from the client side.

Don't throw from ~HttpChunkedEntityWriter after write cancellation.

In theory KJ style should allow this to be caught (it doesn't throw if another exception was already thrown), but I've observed this producing an std::terminate() for some reason.

Improve HTTP body cancellation handling.

Implement newHttpClient(HttpService&).