We have our api hosted here: http://api.keatech.com
If you look at OpenAPI spec here: https://api.keatech.com/openapi/v1/openapi.json, you will see that server name here is incorrect one: "https://keatech-public-api.azurewebsites.net".
It's all okay with Swagger spec though: https://api.keatech.com/swagger/v1/swagger.json The server listed is "api.keatech.com" which is what we expect here.
Some addiotional info: api.keatech.com is a CNAME record which points to keatech-public-api.azurewebsites.net.
@RSuter I'm not quite sure why you labelled this is a question and not a bug... Is this intended behavior? If yes, could someone point me into a right direction to achieve the desired behavior?
@RicoSuter Looks like this has been (accidentally?) fixed in one of the latest releases. We really lack a changelog in this great project. In case, thanks a lot for your great work!
For a “changelog” you can check the commits list:
https://github.com/RicoSuter/NSwag/commits/master
I know a real changelog would be better but i only have limited time to work on this
Any idea why this has been fixed?
@RicoSuter Nope. And... now it is broken again :( I will try to bisect and find which version worked. Or, may be, it's some kind of heisenbug ..
I think this would help you:
https://github.com/RicoSuter/NSwag/wiki/AspNetCore-Middleware#hosting-as-an-iis-virtual-application-or-behind-a-reverse-proxy
Or just do a postprocess in addswaggerdocument() and useswagger()
I'm sorry, but neither of these helps. I will try to look at this issue later again and see if i can find where this server list is populated. May be that will give us the answer.
Okay, and now it's fixed (again?) with the latest release (12.2.4).
@RicoSuter did you do anything specific to address this issue? May be it was fixed by https://github.com/RicoSuter/NSwag/pull/2130 ?
If not, it might be something MS is doing to Azure servers that is changing this behavior.
@dmytro-gokun if it was called for different hosts before then this could have solved it...
@RicoSuter Well, at least not explicitly. As I stated earlier, it is hosted in Azure and the default DNS name they assigned is "keatech-public-api.azurewebsites.net". We then have a CNAME record of our own. "api.keatech.com" which points to "keatech-public-api.azurewebsites.net".
Anyway, it works as expected now and that's what is important.
Thanks again for the work you put in (B).
Well, at least not explicitly. As I stated earlier, it is hosted in Azure and the default DNS name they assigned is "keatech-public-api.azurewebsites.net". We then have a CNAME record of our own. "api.keatech.com" which points to "keatech-public-api.azurewebsites.net".
Maybe Azure Web App calls the azurewebsites.net endpoint to check whether the site is up and then it cached the spec based on this host and the external host didnt work anymore... and now with this caching change it just works? Just a guess TBH