Re: Serverside SNI support in libpq

On Wed, Dec 17, 2025 at 4:07 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> > Will anyone be mad at us for camping on the "no_sni" identifier? I
> > know technically underscore isn't allowed in DNS hostnames, buuuut [1,
> > 2]
>
> Maybe, but I think that regardless of what we do someone will be mad.  The
> other option would be to use another single character like '?' or something.
> Not sure that will improve readability though.

Hm, I agree that's not readable. Especially since other famous server
implementations use ? to match a single character in server alias
names.

Maybe we could enclose no_sni with something that's emphatically not
DNS. Braces, brackets, etc.? If we had control over the lower level
tokenizer, we could tell people to double-quote it to disambiguate,
but I don't think we have access to that information at our level.

> > Should we support multiple hostname tokens in a single line, though,
> > and just copy the settings that follow across all of them?
>
> I've been hesitant to add too much complexity, but perhaps just allowing a
> comma separated list is a good middle ground to avoid going full regex?

I think it could be a pretty good bump in usability. Wildcards seem
ideal but the cost is much higher. Hopefully the cost of
comma-separated hosts is just an extra inner loop in the parser, plus
the extra tests?

I'm trying to put on my "what could we possibly regret" hat for these
next ones. They may be uselessly speculative:

- If the goal is to eventually support wildcards, will the use of a
bare catch-all asterisk conflict with your plans (if any)?
- What kind of normalization should we do? Currently, `example.com`
will not match `example.COM` and it seems like that might be a problem
for somebody.
- Do we need to consider IDNs and A-labels and U-labels? (Do we
support the latter today, at all?)

A nice-to-have v2ish feature might be to warn if the host configured
for a certificate cannot in fact match that certificate according to
OpenSSL.

--Jacob