A client fetches the generated WSDL through a load balancer and the soap:address points to an internal host. How does Spring-WS solve this, and what are the tradeoffs of location transformation?

## The problem The generated WSDL advertises the endpoint in its `<soap:address location="..."/>`. That value originates from `DefaultWsdl11Definition.setLocationUri(...)`. Teams often set it to a relative path like `/ws` or an internal URL. When a client behind a **reverse proxy / load balancer** downloads the WSDL, it needs the *public* URL (correct scheme, host, port, context path) to actually POST SOAP requests. A hard-coded internal value makes the WSDL non-actionable externally. ## The Spring-WS mechanism `org.springframework.ws.transport.http.MessageDispatcherServlet` exposes **`setTransformWsdlLocations(boolean)`**. When `true`, before streaming a `WsdlDefinition`, the servlet runs a transformation that rewrites `location` attributes (SOAP address, and also schema import/include locations for served schemas) to reflect the **current HTTP request**: it uses the request's scheme, server name, server port, and context/servlet path to build the base URL, and substitutes it into relative/placeholder locations. So a client hitting `https://api.example.com/ws/countries.wsdl` sees `location="https://api.example.com/ws"` regardless of the internal `locationUri`. There is an analogous `setTransformSchemaLocations(true)` for served XSDs (`XsdSchema` beans exposed via the servlet), which rewrites `schemaLocation` references similarly. ## Why a load balancer breaks it further The transformation uses what the servlet *thinks* the request URL is. Behind a proxy that terminates TLS and forwards over HTTP, the servlet may see `http` and the internal host/port unless the proxy sets **`X-Forwarded-Proto`/`X-Forwarded-Host`/`X-Forwarded-Port`** *and* the app honors them. In Spring Boot that means enabling forwarded-header handling (`server.forward-headers-strategy=framework` which registers a `ForwardedHeaderFilter`, or `native` to let the container do it). Without it, `transformWsdlLocations` faithfully rewrites to the *wrong* (internal, `http`) address — arguably worse than a static value because it looks authoritative. ## Tradeoffs / when to use which - **Transformation ON + forwarded headers correct**: best for multi-environment deploys where the public URL varies (dev/stage/prod, blue-green, arbitrary hostnames). No redeploy needed when the host changes. - **Transformation OFF + absolute public `locationUri`**: deterministic, contract-stable; the WSDL always says the same thing. Cost: you must update config and redeploy if the public endpoint changes, and a single WSDL can't serve multiple hostnames correctly. - **Frozen static WSDL (`SimpleWsdl11Definition`)**: maximum contract stability / byte-for-byte control; you own address correctness manually. ## Security & correctness notes - Rewriting from the `Host` header means the advertised address is influenced by client-supplied input; combined with trusting `X-Forwarded-*`, ensure only your trusted proxy can set those headers (host-header injection could otherwise make the WSDL advertise an attacker-chosen host to that same caller — low impact but worth knowing). - Caching: if a CDN caches the WSDL response, a per-request rewrite is undermined — vary/no-cache appropriately or disable transformation and use a fixed URL. - The transform only fixes advertised locations; it does not change routing. The servlet mapping (`/ws/*`) still determines what actually handles requests. ## Summary `setTransformWsdlLocations(true)` is the idiomatic fix, but it's only correct if the app resolves the real external request URL — which behind an LB requires forwarded-header support. Otherwise prefer a pinned absolute `locationUri`.