You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Swashbuckle includes a beautiful feature that allows swagger.json to be found completely dynamically: if its specified URL is relative, then the client makes it absolute based on where it is accessing index.html:
This takes care of any potential proxy issues, no matter how convoluted. I'd love to see the same for the actual API endpoints!
To give some context, my setup is as follows:
App with Swagger UI is running in Kubernetes, accessible at http://[Whatever]/api/.
Internal proxy forwards https://[InternalHost]/demo/demo-api/api/ to the app.
External proxy forwards https://[ExternalHost]/demo/api to the internal proxy.
As we can see, both host and base path are different each time.
Situation 1 is comparable to running locally, meaning it needs to work correctly. Situation 2 and 3 are also both accessed, so they each need to work correctly as well.
Sadly, the internal proxy does not forward the external proxy's X-Forwarded-* headers in any way. The app does not receive any X-Original-* headers, and the X-Forwarded-* headers are unusable in situation 3.
If the client side would resolve relative API endpoint paths like it does for swagger.json, the issue would be resolved for all cases.
The text was updated successfully, but these errors were encountered:
Swashbuckle includes a beautiful feature that allows
swagger.json
to be found completely dynamically: if its specified URL is relative, then the client makes it absolute based on where it is accessingindex.html
:Swashbuckle.AspNetCore/src/Swashbuckle.AspNetCore.SwaggerUI/index.html
Line 82 in 8f363f7
This takes care of any potential proxy issues, no matter how convoluted. I'd love to see the same for the actual API endpoints!
To give some context, my setup is as follows:
http://[Whatever]/api/
.https://[InternalHost]/demo/demo-api/api/
to the app.https://[ExternalHost]/demo/api
to the internal proxy.As we can see, both host and base path are different each time.
Situation 1 is comparable to running locally, meaning it needs to work correctly. Situation 2 and 3 are also both accessed, so they each need to work correctly as well.
Sadly, the internal proxy does not forward the external proxy's
X-Forwarded-*
headers in any way. The app does not receive anyX-Original-*
headers, and theX-Forwarded-*
headers are unusable in situation 3.If the client side would resolve relative API endpoint paths like it does for
swagger.json
, the issue would be resolved for all cases.The text was updated successfully, but these errors were encountered: