Kestrel outputs to console an http url for non-http connection handlers

[mconnew]

Describe the bug

When running the WebHost for an application, Kestrel outputs a list of Uri's that it's listening on. When using a custom ConnectionHandler with Kestrel which isn't http, it outputs the uri with an http scheme. You will see a line such as the following:

Now listening on: http://0.0.0.0:8808

To Reproduce

1. Using Microsoft.AspNetCore.App version 2.2.0
2. Add a custom ConnectionHandler for Kestrel to use with a unique listening endpoint
3. Build IWebHost and call Run()
4. See the previously mentioned console output showing the listening endpoint but with the http scheme

Expected behavior

The ideal thing would be to be able to specify the scheme as part of either the config or a virtual property on ConnectionHandler but that's new api and a feature request. Without new api, output the listening endpoint instead of a Uri. e.g.:

Now listening on: 0.0.0.0:8808

[analogrelay]

Yeah, we should probably clean this up. Won't have time to fix it in 3.0 since our focus is generally HTTP right now but I like it.

[davidfowl]

It can be done as part of this PR #11109

[davidfowl]

@anurse 3.1 candidate?

[jacobslusser]

The addresses displayed in the console are stored in the IServerAddressesFeature. I found several tests assuming the scheme will always be http(s) which would need changing, but AFAIK there are not any other runtime components that are using IServerAddressesFeature in a significant way that would break.

Still, the IServerAddressesFeature.Addresses is a public type and member so there is the possibility of other users expecting it to also be http(s).

So, what to do?

1. Simplest would be to just trim the http(s):// prefix from the log/Console output. Treat it as a display-only issue.
2. Update the actual addresses stored in the IServerAddressessFeature and hope that it is not too breaking a change for anyone consuming it.
3. Add another member to IServerAddressesFeature that is the proper address list and leave the original Addresses property untouched. Or a completely new feature.

I'm interested in creating a PR for this, but need some direction on what the best way to go is.

[jacobslusser]

#30792 suggests non-http(s) addresses are already being added to the IServerAddressesFeature. So, less reason to worry about breaking any callers if that is already the standard behavior.

It also means I was looking at this wrong. The correct fix would be to change where the addresses are being inserted into the collection and what is formatting them. It looks to be ListenOptions (and derivatives) that call the GetDisplayName method and Scheme property which makes no allowances for non-http(s) schemes.

It could be as simple as updating the Scheme property to return tcp:// or similar when appropriate.

[mconnew]

Unless something was changed in later versions, the output listening addresses aren't being pulled from IServerAddressesFeature. I have CoreWCF populating that with a net.tcp:// address. The "Now listening on" text uses/used the GetDisplayName method and doesn't use IServerAddressesFeature at all.

[TiWi79]

Hey there! Just stumbled across this issue, while trying to "convince" Kestrel to display "TCP" instead of "http://".
Any progress with this since @mconnew opened the issue in 2019? Can we make Kestrel display anything else than "Now listening on: http://...."? Would be nice.
Thanks.