- 19 Feb, 2019 2 commits
-
-
Kenton Varda authored
Fix compile error with Array<const T>.
-
Kenton Varda authored
For trivial types, we already had this const_cast (line 622), but for non-trivial types it was missing.
-
- 12 Feb, 2019 2 commits
-
-
Kenton Varda authored
Update rpc.capnp
-
0xflotus authored
-
- 09 Feb, 2019 2 commits
-
-
Kenton Varda authored
Fix obscure optimization-blocking bug in PromiseIoStream::tryPumpFrom().
-
Kenton Varda authored
I don't have a use case, I was just reading the code and noticed it was wrong.
-
- 05 Feb, 2019 1 commit
-
-
Kenton Varda authored
-
- 04 Feb, 2019 2 commits
-
-
Kenton Varda authored
Fix obscure use-after-free in HttpClientAdapter.
-
Kenton Varda authored
In setPromise() we chain `task` with an error handler that accesses ResponseImpl, so that means `task` needs to attach a reference to RespnoseImpl... ugh.
-
- 23 Jan, 2019 3 commits
-
-
Kenton Varda authored
Typos in comments
-
Max FERGER authored
-
Max FERGER authored
-
- 22 Jan, 2019 12 commits
-
-
Kenton Varda authored
Make HttpServer detect client disconnect and cancel request processing
-
Kenton Varda authored
-
Kenton Varda authored
Skip whenWriteDisconnected() tests on Cygwin, where they don't seem to work -- the promise never resolves.
-
-
Kenton Varda authored
Fix HttpClient-from-HttpService wrapper prematurely cancelling service promise.
-
Kenton Varda authored
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.
-
Kenton Varda authored
-
Kenton Varda authored
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.)
-
Kenton Varda authored
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.
-
Kenton Varda authored
This will allow the HTTP server to detect when a client has disconnected and cancel processing the response.
-
Kenton Varda authored
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.
-
Kenton Varda authored
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.
-
- 12 Dec, 2018 1 commit
-
-
Kenton Varda authored
Log more info in VectorOutputStream::write() KJ_REQUIRE
-
- 11 Dec, 2018 6 commits
-
-
Ingvar Stepanyan authored
-
Harris Hancock authored
-
Kenton Varda authored
This seems to be the case, for example, on WSL.
-
Kenton Varda authored
Detect EOF in copyChunk
-
Harris Hancock authored
This is to help debug an issue in Cloudflare Workers. I also added the same debug info to the ArrayOutputStream case, mostly for pleasing symmetry.
-
Ingvar Stepanyan authored
If holes are not supported on the target system and size to `copy` was passed as `kj::maxValue()`, this could lead to near-infinite loops.
-
- 10 Dec, 2018 2 commits
-
-
Kenton Varda authored
Fix cancellation in AsyncTee::PumpSink.
-
Kenton Varda authored
-
- 07 Dec, 2018 4 commits
-
-
Kenton Varda authored
Typo in c++/src/kj/array.h
-
Kenton Varda authored
Fix overflow in PackedInputStream.
-
Simon Struk authored
-
Max FERGER authored
-
- 29 Nov, 2018 2 commits
-
-
Kenton Varda authored
Multi-host HttpClient shouldn't rewrite URL.
-
Kenton Varda authored
-
- 26 Nov, 2018 1 commit
-
-
Kenton Varda authored
Fix typo
-