The problem of the default listening address of.Net9 WebAPI

[zhongbiran]

What happens?

Previously, I defaulted to using urls in appsetting.json as listening, but in the UI it became [::]:9001. Using seed also indicated cross-domain issues. The same SwaggerUI does not have this problem.

What did you expect to happen?

To solve the problem, I used the following code：

var webUrl = config.GetValue<string>("Urls");
builder.WebHost.UseUrls(Regex.Replace(webUrl, "\\*", "localhost"),webUrl);

plesase don't let them happen again

OpenAPI Document

No response

[xC0dex]

Hi,

I’m not entirely sure I understand the issue you're describing. Scalar relies on the generated OpenAPI document and uses the server information provided within it. The document generator in Microsoft.AspNetCore.OpenApi uses the IServerAddressesFeature feature. Perhaps the values from this aren't being generated as expected.

[tom-englert]

I had the same problem, but it only happens in development environment:

appsettings.json:

  "Kestrel": {
    "Endpoints": {
      "Default": {
        "Url": "http://+:8080"
      }
    }
  },
  "AllowedHosts": "*"

launchsettings.json:

"environmentVariables": {
  "ASPNETCORE_ENVIRONMENT": "Development",
  "SystemLog__MinimumLevel__Default": "Debug"
},

Fix:
launchsettings.json:

"environmentVariables": {
  "ASPNETCORE_ENVIRONMENT": "Development",
  "Kestrel__Endpoints__Default__Url": "http://localhost:8080",
  "SystemLog__MinimumLevel__Default": "Debug"
},

[xC0dex]

but it only happens in development environment:

Yes. The link I shared in the previous comment refers to the implementation in the Microsoft.AspNetCore.OpenApi package. There is the condition hostEnvironment.IsDevelopment().

This is not an issue in the Scalar.AspNetCore package.

[tom-englert]

@xC0dex IMO the bug is that scalar is using the "servers" to build the callback address:

{
    "openapi": "3.0.1",
    "info": {
        "title": "MyApi | v1",
        "version": "1.0.0"
    },
    "servers": [
        {
            "url": "http://[::]:8080"
        }
    ],
    "paths": {

This entry is only present in development environment, and it reflects what is configured in kestrel settings, but is not the callback address, that's why it always works in productive environment where the "servers" entry is not present.

[xC0dex]

Probably I didn't get it right, sorry. What do you mean with the callback address?
I only know that there are open discussions and issues regarding the servers property inside the generated OpenAPI document using the Microsoft.AspNetCore.OpenApi generator. The eshop also implements a custom document transformer by overwriting the values.

[tom-englert]

This is an invalid address, so trying to test this request fails.

[tom-englert]

When the "servers" entry is absent, scalar uses the correct host and everything works fine

[xC0dex]

I believe this still seems more like a feature than a bug. SwaggerUI behaves the same way.

If a server key is defined in the OpenAPI document, it will be used as the base URL. IMO, the root cause lies with the Microsoft.AspNetCore.OpenApi document generator. Unlike Swashbuckle or NSwag, which rely on HttpContext to dynamically generate the server URL, this generator uses the IServerAddressesFeature feature. There are some similar issues reported in the AspNetCore repo: dotnet/aspnetcore#59313 and dotnet/aspnetcore#57332.

[tom-englert]

I agree that, looking at the OpenAPI schema documentation, Microsoft seems to be wrong.

The best workaround seems to be the custom document transformer that clears the servers entries to prevent the invalid server entry.

[xC0dex]

I'll close this issue because the bug itself is not Scalar.AspNetCore related. I think with .NET 10 they will address this issue, so I recommend keeping an eye on this issue dotnet/aspnetcore#57332.