- 11 Nov, 2019 1 commit
-
-
Kenton Varda authored
Note that I only care about supporting BoringSSL at master since BoringSSL does not do versioned releases.
-
- 07 Nov, 2019 1 commit
-
-
Kenton Varda authored
This is a no-brainer given AsyncIoStream has getsockopt() and getsockname(), whereas ConnectionReceiver has only getsockopt().
-
- 31 Oct, 2019 1 commit
-
-
Joe Lee authored
Ideally, the HttpClient/HttpServer adapters should maintain the invariant that the behavior of a given client is the same as the behavior of newHttpClient(newHttpService(client)). Prior to this change, the HttpClient wrapper lazily called request(), so a client whose request() eagerly threw an exception could produce a different exception when called directly versus when wrapped -- the laziness allowed additional code to run. This was particularly evident when making a request with a body, since code using a wrapped client would be able to set up a subsequent BlockedWrite, eventually resulting in a "read end of pipe was aborted" exception instead of the actual exception. This change makes HttpClientAdapter::request() execute the wrapped request() eagerly. (Note that it partially undoes 90d48343... Hopefully, it preserves the desired behavior added there.)
-
- 28 Oct, 2019 1 commit
-
-
Kenton Varda authored
And fix a bug detected by this.
-
- 22 Oct, 2019 1 commit
-
-
Kenton Varda authored
-
- 14 Oct, 2019 1 commit
-
-
Vitali Lovich authored
For Visual Studio we have to wrap the headers with push/pop pragmas at the top and bottom of the file. Define common macros for suppress/unsuppress KJ & the appropriate macros for CAPNP begin/end header wrappers. Because there's a chicken egg problem the KJ_BEGIN_HEADER/CAPNP_BEGIN_HEADER macros are placed below all includes to ensure that the appropriate common.h file has been sourced.
-
- 03 Oct, 2019 1 commit
-
-
Kenton Varda authored
-
- 02 Oct, 2019 3 commits
-
-
Kenton Varda authored
For regular (non-RT) POSIX signals, the process can only have at most one instance of each signal queued for delivery at a time. If another copy of the signal arrives before the first is delivered, the new signal is ignored. The idea was that signals are only meant to wake the process up to check some input; the signal itself is not the input. POSIX RT signals are different. Multiple copies of the same signal can be queued, and each is delivered separately. Each signal may contain some additional information that needs to be processed. The signals themselves are input. UnixEventPort's `onSignal()` method returns a Promise that resolves the next time the signal is delivered. When the Promise is resolved, the signal is also supposed to be blocked until `onSignal()` can be called again, so that the app cannot miss signals delivered in between. However, the epoll/signalfd implementation had a bug where it would pull _all_ queued signals off the `signalfd` at once, only delivering the first instance of each signal number and dropping subsequent instances on the floor. That's fine for regular signals, but not RT signals. This change fixes the bug and adds a test. Incidentally, the poll()-based implementation has been correct all along.
-
Kenton Varda authored
I don't really know how to test this since the other cmsg types are bizarre and non-portable, but they do exist.
-
Kenton Varda authored
This and many other characters are surprisingly allowed by the relevant RFCs. But it turns out we implemented the RFCs correctly, so yay.
-
- 30 Sep, 2019 1 commit
-
-
Edward Z. Yang authored
I initially didn't read the docs carefully enough and returned a StringPtr to a locally allocated string. Whoops. Make the doc a little clearer about this.
-
- 16 Sep, 2019 1 commit
-
-
Joe Lee authored
-
- 11 Sep, 2019 5 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Rationale: If this were a native OS pipe, closing or aborting one end would cause the other end to throw DISCONNECTED. Note that dropping the read end of a userland pipe is implemented in terms of aborting it, which makes it even more clear that this is a disconnect scenario.
-
Kenton Varda authored
This is needed now because http-over-capnp will index the Set-Cookie header. This change should make it relatively safe to index Set-Cookie when using KJ HTTP.
-
Kenton Varda authored
- Add a `size()` method. - Add a `forEach()` that enumerates tabled headers by ID, and only uses string names for non-tabled headers.
-
Kenton Varda authored
A pump does not propagate EOF. So a BlockedRead state should not complete when a pump happens that does not satisfy the read.
-
- 10 Sep, 2019 1 commit
-
-
Kenton Varda authored
-
- 09 Sep, 2019 1 commit
-
-
Kenton Varda authored
Most (all?) implementations of `write(ArrayPtr<const ArrayPtr<const byte>>)`, if the outer array contains only one inner array, do not use the outer array again after the initial call returns (as opposed to the promise resolving). But, this is not a safe assumption and http-test.c++ should not be relying on it. (I found this when I tried forcing all writes to complete asynchronously to check if it resulted in any bugs. This is all I found.)
-
- 03 Sep, 2019 3 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
- 20 Aug, 2019 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
- 02 Aug, 2019 1 commit
-
-
Harris Hancock authored
This information is typically necessary to debug such protocol errors. However, it requires special handling, since it could contain sensitive information. The code which has the best view on protocol errors is HttpHeaders::tryParseRequest(), which previously returned an empty Maybe<Request> on failure. This commit changes that function to return a OneOf<Request, ProtocolError>. This required some surgery in various other parts of the code to deal with the OneOf.
-
- 23 Jul, 2019 1 commit
-
-
Harris Hancock authored
-
- 22 Jul, 2019 3 commits
-
-
Harris Hancock authored
The HttpServerErrorHandler is separate from the HttpService interface, because error-handling is more in the domain of the HttpServer, which can export multiple HttpServices (via the factory constructor overload).
-
Harris Hancock authored
I broke this while iterating on the new error handler mechanism, so here's a test.
-
Harris Hancock authored
Maybe<T> has a non-trivial destructor, but there's no point making it constexpr, but Maybe<T&> can be.
-
- 10 Jul, 2019 1 commit
-
-
Kenton Varda authored
I decided that such wrapping did not make senes.
-
- 08 Jul, 2019 10 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
They are more efficient, and self-contained enough not to create trouble. Also, Cygwin's pthread_rwlock implementation appears buggy. I am seeing it allow double locks from time to time.
-
Kenton Varda authored
Also required making KJ_WIN32 macros available on Cygwin. (Cygwin allows direct calls to Win32 functions.)
-
Kenton Varda authored
I observed the cygwin async-xthread-test getting deadlocked here, and noticed the bug. However, the predicate in question was not flappy, so this doesn't really fix async-xthread-test.
-
Kenton Varda authored
-
Kenton Varda authored
A long, long time ago, an early version of the event loop code was multithread-aware and used futexes. I ripped that all out later but apparently didn't remove these includes.
-
Kenton Varda authored
The delay() here isn't long enough on Cygwin when using pipes for wakeup. Apparently, Cygwin pipes are very slow. :/
-
Kenton Varda authored
-
Kenton Varda authored
See my latest report: https://cygwin.com/ml/cygwin/2019-07/msg00052.html We can't use signals for cross-thread wakeups on Cygwin because the same signal cannot be pending on two different threads at the same time. So I broke down and made an implementation that uses pipes. Ugh.
-
Kenton Varda authored
-