Enhance HTTPS redirect middleware for multi-hostname scenarios

[rynowak]

See: dotnet/tye#354

The HTTPS redirect middleware allows you to configure (via config) a single port to use for HTTPS redirects. There are cases where this isn't sophisticated enough because each hostname you're listening on has a different HTTPS port value.

[Tratcher]

Can you clarify why each host has a different port? Hosts can share ports using host headers and SNI.

[analogrelay]

@Tratcher well, if they're different ASP.NET Core apps, we still have the port sharing problem right? Regardless of feasibility, only one process can bind to the port.

[Tratcher]

Nevermind, I just read the linked issue and it's a very different scenario. The app only has one local port. The app accepts requests directly and through a proxy. The host name is the same in both cases, but the public and internal ports are different.

In this example it needs to be able to redirect myhost:80 -> 443 and myhost:4567 -> 4568.

[Tratcher]

Why isn't the front end enforcing its own https?

[rynowak]

As in, have the proxy responsible for the redirect? The proxy in this case is docker I think, not a dedicated proxy server.

[analogrelay]

Is there a proposed new behavior here?

[Tratcher]

The middleware needs to be capable of doing a host+port lookup from IServerAddresses and/or a static list to get the matching https port. A collection of KVP<string, int> is the basic structure.

Note today it throws if trying to auto-configure and it finds more than one https endpoint in IServerAddresses.

[BrennanConroy]

@jkotalik Does Tye have an API proposal for this? Also, how important is this API to Tye?

[jkotalik]

I don't think this critical for Tye, we wouldn't be able to utilize an API change here as we are primarily targeting 3.1.