Re: Proposal: http2 wire format

Hi,

> On 26 Mar 2018, at 06:47, Jacob Champion <pchampion(at)pivotal(dot)io> wrote:
>
> On Sun, Mar 25, 2018 at 8:11 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> As others have noted, you'll want to find a way to handle this in the least
>> SSL-implementation-specific manner possible. IMO if it can't work with
>> OpenSSL, Windows's SSL implementation and OS X's SSL framework it's a
>> non-starter.
>
> +1.
>
>> While I'm a big fan of code reuse and using existing libraries, I understand
>> others' hesitance here. Look at what happened with ossp-uuid; that was
>> painful and it was just a contrib.
>>
>> It's a difficult balance between NIH and maintaining a stable core.
>
> For whatever it's worth, I think libnghttp2 is an excellent choice for
> an HTTP/2 implementation, even when taking into account the risks of
> NIH. It's a well-designed library with mature clients (Curl and Apache
> HTTP Server, among others), and it's authored by an HTTP/2 expert. (If
> you're seriously considering HTTP/2, then you seriously need to avoid
> not-invented-here syndrome. Don't roll your own unless you're
> interested in becoming HTTP/2 protocol-layer security experts in
> addition to SQL security experts.)
>
Agreed.

> As you move forward with the PoC, consider: even if you decide not to
> become protocol-layer experts, you'll still need to become familiar
> with application-layer security in HTTP.

Good point. Application layer security is indeed a concern.

h2 has provisions for security by design, and a significant amount of research going into this on a large scale. Adopting h2 instead of inventing our own v4 gets us all this research for free.

> You'll need to decide whether
> the HTTP browser/server security model -- which is notoriously
> unintuitive for many -- works well for Postgres. In particular, you'll
> want to make sure that the new protocol doesn't put your browser-based
> users in danger (I'm thinking primarily about cross-site request
> forgeries here). Always remember that one of a web browser's core use
> cases is the execution of untrusted code…

Mentioning h2 does bring browsers in mind, but this proposal is not concerned with that. (quick curl sketches are shown only because curl is an already available h2 client). Present web-facing designs already deal with browsers and API clients, there will be no change to that. Existing Postgres deployment and security practices must remain unchanged whether we use v3 or h2. Don’t think anyone would want to expose Postgres to the open web without a connection pooler in front of it.

When you say "browser/server model,” presumably you’re having http1 in mind. h2 does not have much in common with http1 on the wire. In fact, h2 is architecturally closer to febe than http1. Both h2 and febe deal with multiple request/response pairs over a single connection. Server initiated requests are covered through push_promise frames, and logical replication (being more of a subscription thing in my mind) is covered through stream multiplexing.

Let's keep the discussion focused on the wire protocol: the sooner we can get to stable h2 framing in the core, the sooner we’ll be able to experiment with new use cases and possibilities. Only then it will make sense to bring back this discussion about browsers, content negotiation, etc.

Thanks,
Damir

> --Jacob