Skip to content

Microsoft.AspNetCore.OpenApi generates bad server list (no domain), breaking Swagger and Scalar #61252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1 task done
burnchar opened this issue Mar 31, 2025 · 2 comments
Open
1 task done

Microsoft.AspNetCore.OpenApi generates bad server list (no domain), breaking Swagger and Scalar #61252

burnchar opened this issue Mar 31, 2025 · 2 comments
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc feature-openapi

Comments

@burnchar
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

app.MapOpenApi();/services.AddOpenApi(); (Microsoft.AspNetCore.OpenApi 9.0.3 in a .NET 9 web application) generates a bad server list in the OpenAPI document which breaks all systems that use it when an HTTPS cert is used.

Generates:

 "servers": [
    {
      "url": "https://*:10000/"
    },
    {
      "url": "https://valen:10000/"
    }
  ],...

But it should be:

 "servers": [
    { 
      "url": "https://valen.mydomain.com:10000/" 
    }
  ],...

Image

Because it is missing the server's domain and ".com", certs that authenticate "*.mydomain.com" fail and the user sees a completely confusing CORS error when using Swagger, and nothing at all in Scalar.

When I switch back to Swashbuckle to generate the OpenAPI document, that document has no servers list at all. No Swagger drop menu exists. All links are relative and have no issue. Generated URLs for API calls are correct.
It is unclear how to fix or remove the server list short of creating a document transformer. The deployment process (from Rider) makes no obvious use or configuration of environment variables like ASPNETCORE_URLS, nor does the code have any special Kestrel configuration.
The list of servers appears to come from, or at least be related to, IIS bindings:

Image
These bindings work perfectly for every application that does not use Microsoft.AspNetCore.OpenApi.

Expected Behavior

One of:

  • Option to get rid of servers list
  • Smarter handling of FQDN

Some documentation regarding how Microsoft.AspNetCore.OpenApi handles server names would be helpful. I am unable to find such documentation.

Steps To Reproduce

  1. Set up an IIS server with bindings as shown and a *.domain.com cert. In my case, we have multiple servers "valen1", "valen2", which are accessed through HAProxy, but the issue occurs even when we visit a specific server.
  2. Deploy an application to that server which uses Swagger or Scalar. For Swagger, the endpoint should be set to "/openapi/v1.json".
  3. View the OpenAPI document and notice the bad server list which is missing the server name.
  4. Observe that the APIs themselves work without issue, but that Swagger and Scalar try to use the bad server list
  5. Observe that the URLs that are generated due to the bad data are invalid, e.g. https://%2A:10000/SomeApi

Exceptions (if any)

<html>
<body>
<!--StartFragment-->
Failed to fetch.Possible Reasons:CORSNetwork FailureURL scheme must be "http" or "https" for CORS request.
--


<!--EndFragment-->
</body>
</html>

(The problem has nothing to do with CORS)

.NET Version

9.0.201

Anything else?

  • JetBrains Rider 2024.3.6
  • No special configuration for Kestrel or special configuration of env vars
  • Windows Server 2019 and IIS as reverse proxy

C:\Users\cb892961>dotnet --info
.NET SDK:
Version: 9.0.201
Commit: 071aaccdc2
Workload version: 9.0.200-manifests.21502d11
MSBuild version: 17.13.13+1c2026462

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.201\

.NET workloads installed:
[maui-windows]
Installation Source: VS 17.10.35027.167
Manifest Version: 9.0.0/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.0\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: VS 17.10.35027.167
Manifest Version: 18.0.9617/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.0.9617\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: VS 17.10.35027.167
Manifest Version: 18.0.9617/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.0.9617\WorkloadManifest.json
Install Type: Msi

[android]
Installation Source: VS 17.10.35027.167
Manifest Version: 35.0.7/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Install Type: Msi

[aspire]
Installation Source: VS 17.10.35027.167
Manifest Version: 8.2.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.3
Architecture: x64
Commit: 831d23e561

.NET SDKs installed:
7.0.100 [C:\Program Files\dotnet\sdk]
8.0.303 [C:\Program Files\dotnet\sdk]
9.0.201 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download
@ghost ghost added the needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically label Mar 31, 2025
@martincostello martincostello added feature-openapi area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc and removed needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically labels Apr 1, 2025
@martincostello
Copy link
Member

Duplicate of #57332. The fix should ship as part of ASP.NET Core 9.0.4, which I think will be released next Tuesday (the 8th).

@jerchap
Copy link

jerchap commented Apr 4, 2025

I raised a discussion about something similar to this #61324. I don't know if it's the same problem or not, but it seems pretty similar. In my case I have two different servers with a very similar set of bindings for the website on each server, and the servers element populates completely different on both servers, and I don't know why. On one server it has no servers element at all, and on the other it is a list based on the bindings configuration of the web site.

The swashbuckle generated document seems to be much better as it uses a single relative url. I was trying to switch from swagger to Microsoft's openapi implementation, but this issue is preventing me entirely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc feature-openapi
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@burnchar @martincostello @jerchap