search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.2k stars 9.94k forks source link

Add protocol to "Now listening on" logged at startup #15279

Open JamesNK opened 4 years ago

JamesNK commented 4 years ago

On startup ASP.NET Core will log the addresses it is listening on. http vs https gives insight into whether the endpoint is secured with TLS. However there is no way to understand what protocols each endpoint supports. It would be useful when debugging connection errors to have an endpoint's protocol logged.

For example:

Now listening on https://localhost:5000 (HTTP/1.1, HTTP/2)
Now listening on http://localhost:5001 (HTTP/2)
Tratcher commented 4 years ago

This isn't possible with the current infrastructure. Hosting makes these logs and it only has access to IServerAddresses containing a simple list of urls.

To do this we'd have to redesign it so that the servers issued these logs. Even then it would only work on Kestrel. IIS and HttpSys don't have access to this information at startup, only per request.

analogrelay commented 4 years ago

What if we provide a new feature (IServerBindings?) with more detail instead of having servers just dump it to logs? As we expand bedrock and move in to scenarios like QUIC (which binds to UDP ports), we may want more functionality here. For example, when binding to HTTP/1,/2,and /3 the server will actually have two separate bindings (TCP and UDP) even when there is only one "URL".

Tratcher commented 4 years ago

It's still only going to work for Kestrel so a new abstraction isn't needed, Kestrel can log it directly.

analogrelay commented 4 years ago

It's still only going to work for Kestrel

That's not true though. Could ANCM query the bindings for the site (in theory)? Could HttpSysServer? Could some other server support this? I don't think it's unreasonable to spend a little time thinking about a design that's more flexible. Logs are useful for user consumption but hard for code to consume and make decisions with. I'm not saying you're wrong that it may not be worth it but I think it's worth some thought.

analogrelay commented 4 years ago

We'll keep this around to talk about during Bedrock work (cc @davidfowl).

JamesNK commented 4 years ago

I didn't cover who this would be useful for in the original issue: I was mainly thinking of gRPC which requires HTTP/2. It could help end users debug connection errors when HTTP/2 is not correctly configured.

btw I logged this while watching the ASP.NET standup, and saw Kestrel report the same endpoint twice on startup for QUIC 😋

analogrelay commented 4 years ago

btw I logged this while watching the ASP.NET standup, and saw Kestrel report the same endpoint twice on startup for QUIC 😋

Yeah, we saw the same thing ;).

shirhatti commented 4 years ago

Triage decision: This would require a new Server Feature or a breaking change to an existing feature. Probably not happening in 5.0