On Wed, 2022-02-16 at 02:10 -0500, Greg Stark wrote: > On Tue, 15 Feb 2022 at 17:37, Magnus Hagander <mag...@hagander.net> wrote: > > > But I think you'll run into a different problem much earlier. Pretty > > much everything out there is going to want to speak http(s). How are > > you going to terminate that, especially https, on the same port as a > > PostgreSQL connection? PostgreSQL will have to reply with it's initial > > negotiating byte before anything else is done, including the TLS > > negotiation, and that will kill anything http. > > Yeah this is a serious problem. I think there are other even more > compelling reasons someone else was already looking at this so I'm > kind of hoping it solves itself :)
Yeah, this seems like a shoe-in with implicit TLS support and ALPN. So hopefully we can help that piece solve itself. :) That said, I feel like I should probably advise against forwarding HTTP through Postgres. With implicit TLS you should be able to run a reverse proxy out front, which could check the ALPN and redirect traffic to the bgworker port as needed. (I don't think you have to terminate TLS in order to do this -- so channel bindings et al should be unaffected -- but I don't have experience with that.) So Postgres wouldn't have to touch HTTP traffic at all, and the bgworker extension can upgrade its HTTP stack completely independently. (And if you don't want to share ports, you don't have to deploy the proxy at all.) --Jacob