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.35k stars 9.99k forks source link

Endpoints Configuration Schema Case Sensitivity #19836

Closed dotbirdman closed 4 years ago

dotbirdman commented 5 years ago

The documentation says that endpoint names are case-insensitive, however if you were to use "https" in one file and then "Https" in another file (or "HTTPS" in an environment variable), they would be seen as two endpoints by Kestrel's ConfigurationReader calling IConfiguration.GetChildren(). If you were to have different case for your endpoint names using different configuration sources (files, variables, command line, etc) without changing the endpoint URL, you would be presented with a "Failed to bind to address" exception.

I think the documentation should state that endpoint names are case-sensitive and loaded as different endpoints. However this seems to be different from other application configuration use, such as logging, which is case-insensitive.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

guardrex commented 5 years ago

Thanks @dotbirdman ... I'll add the PU label to this for engineering to take a look on the next engineering doc issue review.

Rick-Anderson commented 4 years ago

@jkotalik please review ConfigurationReader calling IConfiguration.GetChildren()

analogrelay commented 4 years ago

This should probably start as a product bug discussion, to determine if we should consider changing the case-sensitivity. If we decide not to do that, then we can bring it back as a docs bug.

Transferring.

analogrelay commented 4 years ago

@dotbirdman can you provide a runnable sample that reproduces the case-sensitivity issue? I'm seeing case properly ignored when overriding properties between files. If you can show a full runnable example I'll have the full context on what isn't working in your scenario.

dotbirdman commented 4 years ago

I encountered this issue on ASP.NET Core 2.2; it does not seem to be an issue on ASP.NET Core 3.1

This can be replicated using the default template dotnet new web. Add the following to appsettings.json: 

  "kestrel": {
    "endpoints": {
      "https": {
        "url": "https://*:5443"
      }
    }
  }

Then setting the environment variables: ASPNETCORE_KESTREL__ENDPOINTS__HTTPS__CERTIFICATE__PATH="localhost.pfx" and ASPNETCORE_KESTREL__ENDPOINTS__HTTPS__CERTIFICATE__PASSWORD="password"

In 2.2 this would cause a Kestrel exception. In 3.1 it works as documented.

analogrelay commented 4 years ago

@dotbirdman Ok, good to know. Based on that I'm going to close this issue. 2.2 is out-of-support so we wouldn't backport a patch. Let us know either in this issue or via a new issue if this problem reoccurs.