On Sun, Mar 25, 2018 at 8:11 PM, Craig Ringer <cr...@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
