MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PATCH go-gemini] Set req.Host to SNI hostname when available
From: "Adnan Maolood" <me@adnano.co>
To: "Kaleb Elwert" <belak@coded.io>, <~adnano/go-gemini-devel@lists.sr.ht>
Date: Thu, 25 Feb 2021 11:03:14 -0500
Message-Id: <C9IQLMCEZEKO.2CSNUBNR7V183@nitro>
In-Reply-To: <facb754e-8de8-43e0-94ed-c555214b6f05@www.fastmail.com>

On Wed Feb 24, 2021 at 11:56 PM EST, Kaleb Elwert wrote:
> The reason for adding this isn't for limiting what hosts that can be conn=
ected to,
> but routing to different locations for different hosts on in a single ser=
vice. You are
> right that it could be done by calling .TLS().ServerName, however I would=
 argue that
> either exposing the *tls.ConnectionState by default or at least copying o=
ver the
> ServerName makes sense, maybe even both. If we're exposing ServerName,
> it would make more sense to just store the whole ConnectionState on the r=
equest
> anyway, as we've already generated it to get the ServerName.

Right. I just want to avoid populating the request with too much
unnecessary information that lightweight handlers might not need.
See https://github.com/golang/go/issues/5465#issue-51283668

It might be necessary to populate Request.Host to make it easy to
disallow proxy requests. ServeMux should probably be where proxy
requests are disallowed.

Perhaps we could have an accessor method (say, ServerName) that would
generate return TLS().ServerName. We should also probably cache the
*tls.ConnectionState on the first call to ServerName so that we don't
repeatedly generate it. Or perhaps storing it in Request.Host is cleaner
since it matches with the usage of Request.Host on the client side.

Maybe the server should have its own Request type as mentioned in the
issue above.

> > We don't necessarily want to impose the choice of *tls.Conn on Server
> > users, as they might prefer another TLS implementation, or they might
> > use an unencrypted connection if they are sitting behind a TLS reverse
> > proxy.
>
> This is the first I've heard this argument used with Go - are there other=
 TLS
> implementations commonly used in Go? If this is an actual argument, doesn=
't
> the call to Request.TLS() also break?

See https://github.com/golang/go/issues/21753
The call to Request.TLS won't break, it will just return nil.