Re: Add "host" to startup packet

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Lev Kokotov <lev(at)hyperparam(dot)ai>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add "host" to startup packet
Date: 2023-04-02 17:37:55
Message-ID: F8D60DAC-7483-4101-BA52-B450F29F935A@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 2 Apr 2023, at 18:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Greg Stark <stark(at)mit(dot)edu> writes:
>> My question is a bit different. How does this interact with TLS SNI.
>> Can you just use the SNI name given in the TLS handshake? Should the
>> server require them to match? Is there any value to having a separate
>> source for this info? Is something similar available in GSSAPI
>> authentication?
>
> The idea that I was thinking about was to not hard-wire sending the host
> string exactly, but instead to invent another connection parameter along
> the line of "send_host = name-to-send". This parallels the situation in
> HTTP where the "Host" header doesn't necessarily have to match the actual
> transport target.

Since we already have sslsni in libpq since v14, any SNI being well understood
and standardized, do we really want to invent our own parallel scheme?
Alternatively, the protocol in the.PROXY patch by Magnus [0] which stalled a
few CF's ago has similar functionality for the client to pass a hostname.

--
Daniel Gustafsson

[0] https://www.postgresql.org/message-id/flat/CABUevExJ0ifpUEiX4uOREy0s2kHBrBrb=pXLEHhpMTR1vVR1XA(at)mail(dot)gmail(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-04-02 17:40:05 Re: O(n) tasks cause lengthy startups and checkpoints
Previous Message Peter Geoghegan 2023-04-02 17:22:18 Re: Pass heaprel to GlobalVisTestFor() in vacuumRedirectAndPlaceholder()