dotnet / dotnet/aspnetcore

Expose configured endpoint names on ListenOptions

Open
#67,619 0 comments 0 reactions 0 assignees View on GitHub
area-networking
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 6h
Merged PRs (30d)
290

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Kestrel endpoint names are available while configuration is being processed, but they are not preserved on the resulting `ListenOptions`.

For example, given the following configuration:

```json
{
"Kestrel": {
"Endpoints": {
"Api": {
"Url": "http://*:5200"
},
"Management": {
"Url": "http://*:9200"
}
}
}
}
```

or equivalent Aspire configuration:

```csharp
builder.AddProject()
.WithEndpoint(name: "Api")
.WithEndpoint(name: "Management");
```

The property would contain the configured endpoint name (`Api`, `Management`, etc.) when the endpoint originates from configuration or Aspire, and `null` for endpoints created directly in code.

### Additional context

Today the endpoint name is only used during configuration loading to locate the corresponding endpoint configuration callback.

After that, the information is effectively discarded even though it represents a stable logical identifier chosen by the application developer.

Libraries that need to associate runtime listeners with application configuration currently have to infer this by comparing transport details such as ports or URLs, which is fragile because those values may change independently of the logical endpoint identity.

One example is a custom transport-level network access policy library (not part of ASP.NET Core):

```csharp
services.AddNetworkAccessBuilder()
.AddPolicy("Management", policy =>
{
policy
.RequireEndpoint("Management")
.RequireNetworkGroup("Management");
});
```

Such policies are intended to target logical Kestrel endpoints rather than transport details like ports or URLs.

### Describe the solution you'd like

Expose the configured endpoint name as a public property on `ListenOptions`.

For example:

```csharp
public sealed class ListenOptions
{
public string? EndpointName { get; }
}
```

When `ListenOptions` is created from a named endpoint (for example from the `Kestrel:Endpoints` configuration section or Aspire endpoint configuration), the property should contain that configured endpoint name.

For endpoints created directly in code (for example via `Listen(...)`), the property could be `null` unless a name is explicitly assigned in the future.

This would allow infrastructure libraries to reliably associate runtime `ListenOptions` instances with the logical endpoints defined by the application, without relying on transport details such as ports or URLs.

Contributor guide

Open the contributing guide

Research direction

Start with the public ListenOptions type and the Kestrel endpoint configuration path described in the issue. Trace how named endpoints from Kestrel:Endpoints and Aspire become ListenOptions, then verify that directly configured listeners remain unnamed. Done means the configured name is exposed for named endpoints and is null for endpoints created directly in code.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend, networking
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.