Calling Swagger UI via different context paths fails

[hwanders]

Requesting the Swagger UI from two different public URLs having different context paths causes the second UI initialization to fail. The second UI call will have a wrong path written in swagger-initializer.js: configUrl is based on the path from the first request.

To Reproduce Setup a reverse proxy (for example at localhost:80) in front of a backend service BS (for example at localhost:8080) which adds a prefix to all the backend service's URLs. So the backend service endpoints are available at http://localhost:80/service/** (reverse proxy with path prefix /service) and http://localhost:8080/** (backend service). The backend service should be configured to provide a Swagger UI.

The following scenarios, each executed on a freshly restarted backend service, reproduce the problem:

• First reverse proxy - then backend service
  1. Call the UI via the reverse proxy (works fine)
  2. Call the UI via the service without the reverse proxy (fails)
• First backend service - then reverse proxy
  1. Call the UI via the service without the reverse proxy (works fine)
  2. Call the UI via the reverse proxy (fails)

I'm using springdoc-openapi-starter-webmvc-ui version 2.6.0.

Reason SwaggerIndexPageTransformer initializes the singleton SwaggerUiConfigParameters by calling swaggerWelcomeCommon.buildFromCurrentContextPath(request) if the configuration's configUrl is null. The configUrl (and perhaps some other properties) is derived from the current request's context path.

Subsequent requests, even if they have a different context path, will use the initialized configuration without re-evaluating it. The browser will then try to load the configuration from an URL which is not available.

Expected behavior The configUrl should be re-evaluated (if necessary) to generate a correct swagger-initializer.js.

Ideas Perhaps the SwaggerUiConfigParameters shouldn't be modified at all by the transformer. This is to avoid concurrency problems caused by a hypothetical re-evaluation overwriting the configuration.

I'm not sure whether SwaggerUiConfigParameters.configUrl is a relevant public API for anybody. Changing or removing it is probably a breaking change.