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.)
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. 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...
--Jacob
