This is a Tomcat configuration matter rather than an image bug. By default Tomcat does not honor the X-Forwarded-* headers, so when a reverse proxy terminates TLS and forwards to XWiki over plain HTTP, the Servlet API (request.getScheme(), isSecure(), getRequestURL(), getServerPort()) reports the internal http scheme/port — hence the wrong URLs (e.g. redirects dropping to http://, or {{https://host:80/}}).
Note that the linked XWIKI-18714 (fixed in 12.10.8 / 13.5) already made XWiki's ownXWiki#getRequestURL independent of the application server by reading the forwarded headers itself (HttpServletUtils#getSourceURL). What remained affected is any code path still going through the raw Servlet API (third-party extensions, some auth/redirect flows such as OIDC), which explains the later reports here.
The proper fix on the container side is to make Tomcat trust the proxy headers via a RemoteIpValve. Rather than shipping/toggling this in the image (reverse-proxy setups are too heterogeneous, and the proxy-side header configuration must be done by the user anyway), we've documented it in the README, with a ready-to-use context.xml snippet and the compose/run mount, plus the required nginx headers: https://github.com/xwiki/xwiki-docker/blob/master/README.md#running-behind-a-reverse-proxy
This complements the general [HTTP Reverse Proxy|https://www.xwiki.org/xwiki/bin/view/documentation/xs/admin/installation/http-reverse-proxy/] documentation. With the RemoteIpValve in place the forwarded scheme/port are applied to all requests, resolving the public-address problem. I'm therefore closing this as documented — please reopen if a case remains unaddressed.
Vincent Massol on 19/Jul/26 10:34
This is a Tomcat configuration matter rather than an image bug. By default Tomcat does not honor the {{X\-Forwarded\-\*}} headers, so when a reverse proxy terminates TLS and forwards to XWiki over plain HTTP, the Servlet API \({{request.getScheme\(\)}}, {{isSecure\(\)}}, {{getRequestURL\(\)}}, {{getServerPort\(\)}}\) reports the internal {{http}} scheme/port — hence the wrong URLs \(e.g. redirects dropping back to {{http://}} plain HTTP, or {{[https:// the publichost: being generated with the internal port such as port80/}}|https://host:80/}}]\).
Note that the linked XWIKI\-18714 \(fixed in 12.10.8 / 13.5\) already made XWiki's _own_ *own* {{XWiki#getRequestURL}} independent of the application server by reading the forwarded headers itself \({{HttpServletUtils#getSourceURL}}\). What remained affected is any code path still going through the raw Servlet API \(third\-party extensions, some auth/redirect flows such as OIDC\), which explains the later reports here.
The proper fix on the container side is to make Tomcat trust the proxy headers via a {{RemoteIpValve}}. Rather than shipping/toggling this in the image \(reverse\-proxy setups are too heterogeneous, and the proxy\-side header configuration must be done by the user anyway\), we've documented it in the README, with a ready\-to\-use {{context.xml}} snippet and the compose/run mount, plus the required nginx headers: [https://github.com/xwiki/xwiki\-docker/blob/master/README.md#running\-behind\-a\-reverse\-proxy|https://github.com/xwiki/xwiki-docker/blob/master/README.md#running-behind-a-reverse-proxy]
This complements the general \[HTTP Reverse Proxy|[https://www.xwiki.org/xwiki/bin/view/documentation/xs/admin/installation/http\-reverse\-proxy/|https://www.xwiki.org/xwiki/bin/view/documentation/xs/admin/installation/http-reverse-proxy/]\] documentation. With the {{RemoteIpValve}} in place the forwarded scheme/port are applied to all requests, resolving the public\-address problem. I'm therefore closing this as documented — please reopen if a case remains unaddressed.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
