IISHttpServer populates IServerAddressesFeature.Addresses with non-http addresses

[mconnew]

Describe the bug

When hosting an ASP.NET Core app in IIS using InProcess hosting, when getting the list of addresses from the IServerAddressesFeature feature, it includes non-http addresses if IIS is configured to use non-http bindings such as net.tcp.

To Reproduce

Default hello world asp.net core app configured to use IIS in process hosting. Install non-http transport WCF transport support in Windows .NET features.

Configure IIS to have non-http bindings.

Get the addresses:

IServer server = _serviceProvider.GetRequiredService<IServer>();
IServerAddressesFeature addresses = server.Features.Get<IServerAddressesFeature>();

The addresses collection will contain the addresses:

• http://*:80/APPPATH
• net.tcp://:APPPATH
• net.pipe://:/APPPATH

Even though I didn't list it here, the net.msmq address is likely to also show up in the list if enabled in IIS.

Exceptions (if any)

Only get an exception when trying to parse with Uri, but that's an issue with my code presuming all addresses are http[s]

Further technical details

• ASP.NET Core version : 2.1
• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: 16.9.0

  
  .NET SDK (reflecting any global.json):
  Version:   5.0.200
  Commit:    70b3e65d53

Runtime Environment: OS Name: Windows OS Version: 10.0.19042 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\5.0.200\

Host (useful for support): Version: 5.0.3 Commit: c636bbdc8a

.NET SDKs installed: 2.1.813 [C:\Program Files\dotnet\sdk] 2.2.401 [C:\Program Files\dotnet\sdk] 2.2.402 [C:\Program Files\dotnet\sdk] 3.0.103 [C:\Program Files\dotnet\sdk] 3.1.112 [C:\Program Files\dotnet\sdk] 5.0.103 [C:\Program Files\dotnet\sdk] 5.0.200 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.All 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[shirhatti]

Does anything break at runtime? (Maybe HttpsRedirectionMiddleware?)

[mconnew]

CoreWCF breaks, so I'm putting in a workaround.

[BrennanConroy]

This seems like the expected behavior. The server is listing the addresses associated with it.

Does configuring Kestrel with these bindings have the same behavior?

[mconnew]

@BrennanConroy, are you saying that ASP.NET Core can dispatch Net.Tcp and Net.Pipe requests when hosted in IIS? I would be very surprised if that's the case as you need a .NET Core implementation of the WCF binding NetNamedPipe to communicate with SMSvcHost in order to dispatch requests from those addresses, and NetNamedPipe binding doesn't exist yet on .NET Core. Kestrel doesn't know anything about Net.Tcp or Net.Pipe so can't bind to those.

[BrennanConroy]

Simple fix would be to make IISServer filter the collection. We don't want to do this.

We could also consider a design for something like registering server address types based on available transports. Lets just trust the user/transports.

We need to fix BindingAddress to support wildcards.

We don't want to hide server addresses from the feature so we'll keep them and just fix the BindingAddress class.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[mconnew]

@BrennanConroy, are you saying that even though the IIS IServer can't handle the other transports, that there's still benefit in exposing them to application code?

[davidfowl]

Filtering here feels like the wrong behavior. I think it's less to do with how the server binds and more to do with round tripping user specified information.