6.0.7 SwaggerGen - Servers ignoring Forwarding Options

I have a HTTP service behind HTTPS terminated on balancer.

With v5.6.3 the swagger.json generates completely without the servers section and SwaggerUI calls the service via HTTPS no problem. No forwarding settings are needed anywhere in AspNetCore.

Once I upgrade to 6.0.7 the swagger.json file contains a server section and I found no way to remove it. It references to HTTP URL which is wrong according to headers. I’m not sure if the servers section is now required by SwaggerUI, but if not, there should be an option to opt out and remove it.

I tried many ways to make it generate the correct URL like this, but everything was ignored:

var forwardingOptions = new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedProto
};
forwardingOptions.KnownNetworks.Clear();
forwardingOptions.KnownProxies.Clear();
app.UseForwardedHeaders(forwardingOptions);

Once I downgrade to 5.6.3, everything starts working again.

This is swagger.json generated by 5.6.3:

{
  "openapi": "3.0.1",
  "info": {
    "title": "MyService",
    "version": "1.0"
  },
  "paths": {

This is swagger.json generated by 6.0.7:

{
  "openapi": "3.0.1",
  "info": {
    "title": "MyService",
    "version": "1.0"
  },
  "servers": [
    {
      "url": "http://my-service-url.domain.com"
    }
  ],
  "paths": {

Any ideas?

[domaindrivendev]

Now, with the benefit of hindsight, I’m starting to sense it was a mistake to auto-populate the servers section, as leaving it empty appears to yield the best chance (there’s def cases where it doesn’t) of SB “just working” in proxy environments out-of-the-box. I’m thinking of reverting this and instead offering the functionality as an opt-in flag. The question is, should this be a patch, minor version, or major version increment?

[domaindrivendev]

I’ve just reeased 6.1.0, which reverts back to the old behavior (i.e. leaving the servers section empty and returning relative redirects from the SwaggerUI and ReDoc middleware) as this is a far more friendly default for apps running behind proxies. The one remaining gotcha for proxy environments is the URL(s) passed to the SwaggerEndpoint method when configuring the SwaggerUI middleware - as this is from the perspective of code running in the browser, it should be relative to the swagger-ui page itself. I’ve provided the following section in the docs to call this out:

https://github.com/domaindrivendev/Swashbuckle.AspNetCore#working-with-virtual-directories-and-reverse-proxies

@niker @eric-b could you guys please pull down this version and ensure these changes work for you?