Define and implement HTTP-over-Cap'n-Proto.
This allows an HTTP request/response to be forwarded over Cap'n Proto RPC, multiplexed with arbitrary other RPC transactions. This could be compared with HTTP/2, which is a binary protocol representation of HTTP that allows multiplexing. HTTP-over-Cap'n-Proto provides the same, but with some advantages inherent in leveraging Cap'n Proto: - HTTP transactions can be multiplexed with regular Cap'n Proto RPC transactions. (While in theory you could also layer RPC on top of HTTP, as gRPC does, HTTP transactions are much heavier than basic RPC. In my opinion, layering HTTP over RPC makes much more sense because of this.) - HTTP endpoints are object capabilities. Multiple private endpoints can be multiplexed over the same connection. - Either end of the connection can act as the client or server, exposing endpoints to each other. - Cap'n Proto path shortening can kick in. For instance, imagine a request that passes through several proxies, then eventually returns a large streaming response. If the proxies is each a Cap'n Proto server with a level 3 RPC implementation, and the response is simply passed through verbatim, the response stream will automatically be shortened to skip over the middleman servers. At present no Cap'n Proto implementation supports level 3, but path shortening can also apply with only level 1 RPC, if all calls proxy through a central hub process, as is often the case in multi-tenant sandboxing scenarios. There are also disadvantages vs. HTTP/2: - HTTP/2 is a standard. This is not. - This protocol is not as finely optimized for the HTTP use case. It will take somewhat more bandwidth on the wire. - No mechanism for server push has been defined, although this could be a relatively simple addition to the http-over-capnp interface definitions. - No mechanism for stream prioritization is defined -- this would likely require new features in the Cap'n Proto RPC implementation itself. - At present, the backpressure mechanism is naive and its performance will suffer as the network distance increases. I intend to solve this by adding better backpressure mechanisms into Cap'n Proto itself. Shims are provided for compatibility with the KJ HTTP interfaces. Note that Sandstorm has its own http-over-capnp protocol: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/web-session.capnp Sandstorm's protocol and this new one are intended for very different use cases. Sandstorm implements sandboxing of web applications on both the client and server sides. As a result, it cares deeply about the semantics of HTTP headers and how they affect the browser. This new http-over-capnp protocol is meant to be a dumb bridge that simply passes through all headers verbatim.
Showing
This diff is collapsed.
This diff is collapsed.
Please
register
or
sign in
to comment