Re: Proposal: http2 wire format - Mailing list pgsql-hackers

Hi,

> On 26 Mar 2018, at 06:47, Jacob Champion <pchampion@pivotal.io> wrote:
>
> On Sun, Mar 25, 2018 at 8:11 PM, Craig Ringer <craig@2ndquadrant.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.
Adoptingh2 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
onlybecause 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
whetherwe use v3 or h2. Don’t think anyone would want to expose Postgres to the open web without a connection pooler in
frontof it. 

When you say "browser/server model,” presumably you’re having http1 in mind. h2 does not have much in common with http1
onthe wire. In fact, h2 is architecturally closer to febe than http1. Both h2 and febe deal with multiple
request/responsepairs over a single connection. Server initiated requests are covered through push_promise frames, and
logicalreplication (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
soonerwe’ll be able to experiment with new use cases and possibilities. Only then it will make sense to bring back this
discussionabout browsers, content negotiation, etc. 


Thanks,
Damir



> --Jacob