I don't have a use case, I was just reading the code and noticed it was wrong.

In setPromise() we chain `task` with an error handler that accesses ResponseImpl, so that means `task` needs to attach a reference to RespnoseImpl... ugh.

The test "WebSocket pump disconnect on send" tests what happens if a send() throws DISCONNECTED while pumping. The test hung forever with socketpairs because the message fits entirely in the socket's send buffer, and thus send() actually completes before the disconnect occurs. This differs from userspace pipes, where there is no buffering, and so the send() doesn't complete until all data is received.

This could be fixed by sending a very large message, so that the send() actually blocks on the receiver. But, the problem reveals that WebSocket pumps won't notice when the destination disconnects unless the source sends some message through. Now that we have whenWriteDisconnected(), we can fix this and proactively end the pump, which also fixes the test.

In fact, we can and should propagate such disconnects backwards: if the destination disconnects, we should close the source. We can do this by adding an abort() method to WebSocket, which incidentally allows us to remove the internal AbortableWebSocket interface which was used specifically by WebSocketPipeImpl.

This prevents a hanging service from being a permanent memory leak -- as long as the client is still there waiting.

(TCP servers will need additionally to apply connection-level timeouts/keepalives to detect disappearing clients.)

I decided to make the new method pure-virtual as I wanted to make sure that all wrapper streams properly delegate to the inner stream. We wouldn't want e.g. proactive HTTP cancellation to unexpectedly not work when running over TLS.

This reverts the core change from: https://github.com/capnproto/capnproto/commit/6e4c5ce3c9f31a5e79b50cd9eaae6d03106edf98

There are a few reasons to believe that change was wrong:
- It meant that a pump would always throw and catch a DISCONNECTED exception, which violates the rule that we don't throw exceptions in "normal" operation.
- It could lead to trouble when combined with the previous commit, which could delay WebSocket disconnect until the service "completes" -- which would lead to a hang.

The commit message where I introduced this said something about bad behavior on OSX. We should address that directly, if it is still a problem.

The client app will typically discard the returned response body upon reading EOF. However, the server app may not actually be "done" with the service callback yet at this point. Usually it completes very soon after, but it may need another turn or two of the event loop. If the client discards the response body stream, the server-side promise is discarded, cancelling whatever was left. This is awkward, so we should instead delay the client from seeing EOF until the server has actually finished up.

This is to fix a complaint about Cloudflare Workers removing these components as requests pass through, which apparently breaks someone's funky URLs.

Arguably "." and ".." processing presents a similar problems. But, allowing ".." to pass through is much more likely to lead to security problems. Browsers will generally process "." and ".." before sending a request (whereas they won't collapse double-slashes), so we're following their lead here.

In Cloudflare Workers, we've observed applications in the wild that continue to send messages after a Close message. This is incorrect, but it happens, and we end up logging a spurious error as we attempt to proxy the message through.

By removing this restriction, we can now proxy these WebSockets despite the incorrect usage.

There is currently no way to explicitly omit a Content-Length/Transfer-Encoding header on an HTTP response to a HEAD request. This is awkward for a proxy, which would ideally pass along responses as-is, even if they have no such headers.

This change allows an author to pass zero as the expected body length to HttpService::Response::send() to mean "do not set any body header." This means that a proxy might strip Content-Length: 0 headers, but will never add a Content-Length header where there was none before.

Some protocols, like Visual Studio Code's Language Server Protocol, have made the unfortunate decision to use HTTP-style message envelope even though they are not HTTP protocols. LSP, for example, sends each JSON-RPC messages as a Content-Length header followed by two CRLF followed by a JSON message of that length. I didn't want to rewrite HTTP parsing, so I extended the HTTP library to make this functionality reusable.

These errors apparently don't show up until the first read with 1.1.1, and may have different messages.

Apparently this landed on my Debian machine *today* and then all of the sudden the test was failing. I was so confused.

To safely use HttpHeaders::serialize*() with overridden connection-level headers, dependent code must stay up-to-date with any changes in the builtin header list. We now expose CONNECTION_HEADERS_COUNT and its friends to facilitate this.

This should be treated as the other end disconnecting, not an error.

This is not related to tables but is needed for the Cloudflare Workers runtime change I'm working on that also uses tables... so I'm throwing it into the same PR.

This is stupid, but the GCC maintainers refused to change it:

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425

For some reason, KJ's uses of (void) did not warn with GCC 5 but do warn with GCC 7. Supposedly, GCC *never* supported silencing with (void), so there must have been some other bug that caused GCC to fail to trigger the warning previously -- maybe related to the fact that the values being returned are non-trivial types?

C++17 introduces `[[nodiscard]]` which is defined as being squelchable using `(void)`, but we're still on C++14, and KJ_UNUSED_RESULT is a post-declaration attribute so can't be defined in terms of the new C++17 attribute even if the compiler supports it. Sigh.

Printf debugging at its finest.

Before this change, if *either* the `from` or the `to` end of the pump threw a DISCONNECTED exception, we'd then try to call `to.disconnect()`. But if the exception had been thrown from `to` in the first place, then this would throw again, this time complaining about a previous write not having completed. But the whole point was always to propagate errors from the *receiving* end to the sending end. An error on the sending end should just propagate up the stack.

Move generic gzip output operations to private helper for easier sharing of capabilities between GzipOutputStream and GzipAsyncOutputStream.

 - Makes it possible to decompress data granularly via push-based API.
 - Adds ability to flush output at an arbitrary point.
 - Removes manual `ended` check as zlib checks it for us.

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.

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.

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.

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