- 07 Oct, 2018 1 commit
-
-
Kenton Varda authored
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.
-
- 31 Aug, 2018 1 commit
-
-
Kenton Varda authored
-
- 26 Aug, 2018 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
- 10 Aug, 2018 1 commit
-
-
Harris Hancock authored
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.
-
- 07 Jun, 2018 1 commit
-
-
Harris Hancock authored
-
- 24 Apr, 2018 1 commit
-
-
Kenton Varda authored
-
- 22 Apr, 2018 1 commit
-
-
Kenton Varda authored
It turns out wrapping an HttpService in an HttpClient is considerably more complicated than vice versa, due to the need for pipes. This commit adds a WebSocket pipe implementation very similar to the recent byte-stream pipe (though considerably simpler since there's no need to deal with mismatched buffer sizes).
-
- 09 Apr, 2018 1 commit
-
-
Kenton Varda authored
Previously, the app could control Content-Length by passing `expectedBodySize`. This is great for enabling code that "just works" by handling GET and HEAD requests identically. However, in somewhat more-complicated situations -- especilaly in proxies -- you end up having to write special-case hacks for HEAD requests to deal with the fact that the body is actually empty, but has a non-zero "expected" size. We can make life easier for proxies by allowing the application to directly set the Content-Length and Transfer-Encoding headers in the case of HEAD responses, much like we allow applications to set WebSocket-related headers on non-WebSocket requests/responses. This change actually fixes a bug in Cloudflare Workers where Content-Length is not passed through correctly for HEAD responses. No changes are needed on the Workers side (except adding a test).
-
- 23 Feb, 2018 1 commit
-
-
Kenton Varda authored
This allows an application which calls drain() to potentially pass off HTTP connections to a new HttpServer afterwards. Without this, the application has no way to know if the connections are in an indeterminant state. This change also makes it OK for an application to fail to read the whole request body. Previously, if an app returned a response without reading the whole request, an exception would eventually be thrown, but potentially not until the client had initiated a new request on the same connection. The client would then get a spurious 500 error.
-
- 13 Feb, 2018 1 commit
-
-
Kenton Varda authored
Previously HttpService had two virtual methods: request() and openWebSocket(). Since it's legitimate to respond to a WebSocket request with a normal HTTP response, openWebSocket() actually had a default implementation that fell back to request(). In the new design, there is only request(). The HttpService detects a WebSocket request by checking the headers. A convenience method, HttpHeaders::isWebSocket(), is provided for this purpose. The new approach makes life much easier for services composed of many layers. For example, you might write an HttpService implementation which performs some URL or header rewrite and then calls on to another HttpService. Previously, every such wrapper would have to separately handle regular requests and WebSockets, usually with near-identical code. Of course, you could factor out the common code, but in practice this often turned out pretty clunky. Worse, developers would often just omit the openWebSocket() implementation since implementing only request() seems to work fine -- until you need a WebSocket, and everything is broken. With the new approach, you have to go somewhat out of your way to write a wrapper layer that breaks WebSockets. I did not apply the same logic to HttpClient because: 1. It's not as easy: HttpClient's methods return results rather than calling a callback on completion, so unifying the methods would have forced request()'s signature to change. Lots of code would need to be updated, and would likely become uglier, as request() would now have to return a `webSocketOrBody` variant type even when the caller isn't asking for a WebSocket. 2. People don't implement custom HttpClients nearly as often as they implement custom HttpServices.
-
- 11 Feb, 2018 1 commit
-
-
Kenton Varda authored
This is particularly useful for implementing logic to grab the client's IP address and shove it in X-Real-IP.
-
- 04 Feb, 2018 1 commit
-
-
Kenton Varda authored
-
- 18 Jan, 2018 1 commit
-
-
Kenton Varda authored
Although applications in theory shouldn't care to see connection-level headers (e.g. `Transfer-Encoding`), higher-level specs like the JavaScript Fetch API often specify that these headers should be visible, and they can be useful for debugging. So, this change makes it so that the application can see the connection-level headers on incoming requests. For outgoing requests, the application can provide an HttpHeaders object that specifies these headers (important especially for the pass-through case), but the HTTP implementation will ignore them. Additionally, we can now allow the application to set WebSocket connection-level headers on non-WebSocket requests. This is useful for frameworks that emulate WebSocket over HTTP and assume the ability to set WebSocket headers (especially `Sec-WebSocket-Extension`) on regular non-WebSocket HTTP requests.
-
- 11 Jan, 2018 1 commit
-
-
Kenton Varda authored
@kloepper pointed out a while back that every compiler you've ever heard of supports this. Plus, it's more concise, it's not prone to copy-paste errors, and it looks nicer. At the time I wanted to remain consistent and I didn't feel like spending the time to update all my existing code. But, every time I've added a new header since I've cursed the include guard, so I finally broke down and changed it.
-
- 24 Sep, 2017 1 commit
-
-
Kenton Varda authored
We don't support any extensions currently, but it's important that when acting as a proxy, we don't pass through this header, since it could result in the client and server negotiating extensions that the proxy doesn't understand and will botch.
-
- 22 Sep, 2017 1 commit
-
-
Kenton Varda authored
-
- 21 Sep, 2017 1 commit
-
-
Kenton Varda authored
There are actually two new client types: - One which always connects to a given NetworkAddress, but will automatically manage a pool of reusable connections. - One which looks up the remote address based on the URL it is given, and manages a pool of connections for each host. The latter of these two is a "true HTTP client library".
-
- 05 Sep, 2017 1 commit
-
-
Kenton Varda authored
-
- 04 Sep, 2017 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
This really is more of a data structure than a resource type, and it's useful to be able to share it between threads and whatnot.
-
- 18 Aug, 2017 1 commit
-
-
Kenton Varda authored
-
- 15 Aug, 2017 4 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
Still need to add handshake separately.
-
- 26 May, 2017 1 commit
-
-
Kenton Varda authored
This uncovered some bugs and revealed that there was no way to read the Content-Length of a HEAD response. Fixed.
-
- 02 May, 2017 1 commit
-
-
lithium-snepo authored
or, the world's least significant pull request.
-
- 29 Apr, 2017 2 commits
-
-
Kenton Varda authored
This reverts commit f836a5fc.
-
Kenton Varda authored
-
- 27 Apr, 2017 1 commit
-
-
Kenton Varda authored
-
- 27 Jan, 2017 4 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
The old semantics were intended to allow more implementation freedom, but I find in my actual code it's very convenient to rely on the actual implementation details. Other implementations will just have to deal with it.
-
Kenton Varda authored
-
Kenton Varda authored
-
- 24 Jan, 2017 1 commit
-
-
Kenton Varda authored
Properties: - Presented as a LIBRARY, designed to be unopinionated about the application using it. - Uses KJ async framework. - Header parsing is zero-copy. The whole header block is read into a contiguous buffer, then parsed all at once. Avoids complicated state machinery (and is probably pretty fast). - Known headers are parsed to numeric identifiers so that the application doesn't need to look them up by string name. The app registers all headers it is interested in upfront, receiving numeric IDs for each. Some common headers also have pre-defined constants, avoiding the need for registration. - Connection-level headers (e.g. Content-Length, Transfer-Encoding) are handled entirely internally. - WebSocket support (planned). Not done yet: - Implement the version of HttpClient that connects to new servers as-needed, managing a pool of connections. Currently I've only implemented the version that takes a pre-existing connection and speaks HTTP on it. - Implement WebSockets. - Implement plugable transfer encodings (although I guess Chrome doesn't even support transfer encodings other than chunked; maybe it's a lost cause). - Implement HTTP/2, hopefully transparently (... someday).
-