Description
AdkWebServer.addViewControllers() redirects "/" to the root-relative path "/dev-ui":
|
registry.addRedirectViewController("/", "/dev-ui"); |
registry.addRedirectViewController("/", "/dev-ui");
When this app is deployed behind a reverse proxy that strips a path prefix before forwarding the request (a common pattern for platform-managed multi-tenant gateways, e.g. Kubernetes Gateway API HTTPRoute with a URLRewrite/ReplacePrefixMatch filter), the browser follows this redirect to an unprefixed path the proxy has no route for, and the dev UI 404s.
Why this can't be fixed by the app alone with standard Spring mechanisms
Spring's own reverse-proxy support (server.forward-headers-strategy=framework, which installs ForwardedHeaderFilter) is specifically designed to solve exactly this class of problem via the X-Forwarded-Prefix header — but it only works for context-relative redirect targets (ones that do not start with /). I traced this through ForwardedHeaderExtractingResponse#sendRedirect:
path = (path.startsWith(FOLDER_SEPARATOR) ? path :
StringUtils.applyRelativePath(this.request.getRequestURI(), path));
Root-relative targets (starting with /, as "/dev-ui" does) skip the applyRelativePath branch entirely — the one place X-Forwarded-Prefix awareness would apply — so the prefix is never spliced back in, no matter how the proxy is configured.
Proposed fix
Change the redirect target to be context-relative instead of root-relative:
registry.addRedirectViewController("/", "dev-ui");
I verified this doesn't change behavior for the common local/non-proxied case: RedirectView's contextRelative handling only prepends the context path when the target starts with / (so a context-relative target like "dev-ui" is passed through as-is), and the servlet container's own relative-URL resolution for sendRedirect still resolves "dev-ui" against the current request path "/" to "/dev-ui". It does additionally allow server.forward-headers-strategy=framework + an X-Forwarded-Prefix header to correctly restore a proxy's path prefix, fixing the reverse-proxy case with zero app-specific workaround code.
I've opened a PR with this one-line fix plus the corresponding test update: (link to follow)
Environment
- adk-java: current
main (verified against commit e8b1c20)
- Encountered while deploying a Java ADK agent behind a Kubernetes Gateway API
HTTPRoute that strips a per-app path prefix
Description
AdkWebServer.addViewControllers()redirects"/"to the root-relative path"/dev-ui":adk-java/dev/src/main/java/com/google/adk/web/AdkWebServer.java
Line 151 in e8b1c20
When this app is deployed behind a reverse proxy that strips a path prefix before forwarding the request (a common pattern for platform-managed multi-tenant gateways, e.g. Kubernetes Gateway API
HTTPRoutewith aURLRewrite/ReplacePrefixMatchfilter), the browser follows this redirect to an unprefixed path the proxy has no route for, and the dev UI 404s.Why this can't be fixed by the app alone with standard Spring mechanisms
Spring's own reverse-proxy support (
server.forward-headers-strategy=framework, which installsForwardedHeaderFilter) is specifically designed to solve exactly this class of problem via theX-Forwarded-Prefixheader — but it only works for context-relative redirect targets (ones that do not start with/). I traced this throughForwardedHeaderExtractingResponse#sendRedirect:Root-relative targets (starting with
/, as"/dev-ui"does) skip theapplyRelativePathbranch entirely — the one placeX-Forwarded-Prefixawareness would apply — so the prefix is never spliced back in, no matter how the proxy is configured.Proposed fix
Change the redirect target to be context-relative instead of root-relative:
I verified this doesn't change behavior for the common local/non-proxied case:
RedirectView'scontextRelativehandling only prepends the context path when the target starts with/(so a context-relative target like"dev-ui"is passed through as-is), and the servlet container's own relative-URL resolution forsendRedirectstill resolves"dev-ui"against the current request path"/"to"/dev-ui". It does additionally allowserver.forward-headers-strategy=framework+ anX-Forwarded-Prefixheader to correctly restore a proxy's path prefix, fixing the reverse-proxy case with zero app-specific workaround code.I've opened a PR with this one-line fix plus the corresponding test update: (link to follow)
Environment
main(verified against commite8b1c20)HTTPRoutethat strips a per-app path prefix