Swashbuckle.aspnetcore: Server dropdown shows http, while the url is https

[Gevand]

I've upgraded from package version 5.5.1 to 5.6.3 and seeing this issue.

While my api is reachable through https url (http is completely disabled on the server and will cause err_connection_refused)

The server dropdown has the http protocol in it.

I can create my own IDocumentFilter and force the servers in the dropdown to have https in it, but I was wondering what changed to cause this behavior.

The web api runs on linux via a Kestrel service on http://localhost:5000 and Apache is used as reverse proxy in to it when it sees https://myaccountdev... url.

Here is the configurations:
````c#
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo { Title = "Customer Account API V1", Version = "v1" });
});

app.UseSwagger();
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("/swagger/v1/swagger.json", "Customer Account API V1");
c.RoutePrefix = string.Empty;
});
````

[beyondunn]

I have observed the same issue when upgrading from package version 5.5.1 to 5.6.3.

[sbebrys]

From version 5.6.0 server address is trying populated from X-Forwarded- headers, earlier it was skipped so probably browser filled correct server part. Check You reverse proxy that it populates at least X-Forwarded-Host for domain and X-Forwarded-Proto for schema.

I also inwestigated problem with incorrect schema behind reverse proxy and found that the last version treats this in defferent way - for server address it just use request.Schema and request.Host, so You only need turn on .net core (if use > 3.0) auto consume forwarded headers via ASPNETCORE_FORWARDEDHEADERS_ENABLED=true what is great.
But... this code from 28 Sept. wasn't released => https://github.com/domaindrivendev/Swashbuckle.AspNetCore/blob/0e9781214ff7855b4c1e1c1a43769022f603fca1/src/Swashbuckle.AspNetCore.Swagger/SwaggerMiddleware.cs#L42

From other hand current version 5.6.x also is not fine for me because when I use .net for consuming X-Fowarded- headers (for consistent using correct schema in other parts of my service), they are moving to different header names after handling and cannot be used by swagger, so I got http :/ in the end.

So, short question, can we got new fixed version?

[Gevand]

From version 5.6.0 server address is trying populated from X-Forwarded- headers, earlier it was skipped so probably browser filled correct server part. Check You reverse proxy that it populates at least X-Forwarded-Host for domain and X-Forwarded-Proto for schema.

My .net core app has the following configs:
C# services.Configure<ForwardedHeadersOptions>(options => { options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost; });

I looked through the proxy config like you suggested and it seems have the proto hardcoded as http,

<VirtualHost *:80> RequestHeader set \"X-Forwarded-Proto\" \"http\"

probably because the kestrel service runs on http://localhost:5000, I'll experiment to see if making the header https fixes the issue.

[sbebrys]

Yeah, on proxy it shouldn't be hard-coded, but problem could be also in work together last released version of swagger and HttpOverridesMiddleware, because when headers are consumed in this middleware they are also cleaned, so swagger not see it anymore https://github.com/dotnet/aspnetcore/blob/aeb982dc3bb9b171087de0f60a436cfec19a882f/src/Middleware/HttpOverrides/src/ForwardedHeadersMiddleware.cs#L337. Solution is not use HttpOverride with this version of swagger, but this could break other things, or rollback version to 5.5.1 and wait for new release from master where it is now fixed but not released.

[domaindrivendev]

Consolidated into #1953