Attachments - Cant reach this page

Help / Discuss
1

Hi, I inherited an xwiki as our company expanded through merger.
Its on version 17.6.0 as far as I can tell from the website.

We were forced to migrate it and during that migration we changed the url to the site. Updated the home path in the config etc. Remade the certificates, using certbot, and got it all working fine and dandy appart from attachments and information. Their paths seems to be broken and I cannot find any way to correct it. I should mention we did not change any paths internally or did any other changes than move to a new enviroment, new ip with new fqdn.

Copilot suggest that I should delete caches under var/lib/xwiki/data/store (this is the path to the storage we have in the config andwhere all the files seems to be located). However, I am not familiar enough with this setup to just do what Copilot say. Sure I do have backups but still its a production enviroment.

I searched through the forum several times but couldnt find anything matching my issue exactly so if anyone got any ideas to what might be wrong please let me know.

Is reindixeing a thing to test or? Perhaps I should do that regardless to update things?

Regards
Conny

2

Hello. Maybe verify that you don’t have some web server or proxy in front of XWiki and if you doc, check its rules.

3

Hi vmassol.

Thanx for your input. There might be a proxy issue here too, still investigating it, but the main culprit was http2.

Symptoms
We observed that:

XWiki pages loaded normally, but
The attachments page failed to load, and the browser showed ERR_HTTP2_PROTOCOL_ERROR
Direct attachment downloads caused redirects to login, but the viewer page itself still failed even after logging in.
Authentication itself worked, but the attachments viewer still crashed.

This combination looked like an XWiki rights issue at first, but the browser‑side HTTP/2 error was the clue that something else broke the connection.

Root Cause
The issue was caused by Tomcat’s HTTP/2 (h2) support on the HTTPS connector:
In Server.XML<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> had been added during the migration.
XWiki works fine over HTTP/1.1, but our setup (certificate chain, ALPN negotiation, or Tomcat build) caused HTTP/2 to fail specifically on the attachments viewer route.
Edge/Chrome displayed the failure as:

ERR_HTTP2_PROTOCOL_ERROR

This happens before XWiki even renders the page, so authentication and permissions were not the real problem that I suspected at first.

The Solution
I solved the issue by disabling HTTP/2, simply by commenting out the line:
In Server.XML<!-- <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> -->
Then restarting Tomcat.
This forced all HTTPS traffic to use HTTP/1.1, which is fully stable for XWiki and immediately removed the browser protocol error.

Result
After disabling HTTP/2:

The attachments viewer page loads correctly
Attachments download normally
No more redirect loops or ERR_HTTP2_PROTOCOL_ERROR
XWiki behaves consistently again

Between the lines is Copilots assessment:
Why HTTP/2 broke only that page
XWiki’s attachments viewer uses:
dynamic content generation
redirect logic (especially when not authenticated)
various headers related to cookies/session tracking

Some versions of Tomcat + certain browsers will choke on these under HTTP/2 if the TLS setup isn’t exactly perfect (full certificate chain, ALPN negotiation, certain ciphers, etc.).
Switching to HTTP/1.1 sidesteps all that.

There is ways to fix this to work with HTTP2 but I am not sure its worth the trouble. There is not much benefit to get HTTP2 working.
At least not that I can see right now regarding security and performance.

I am glad its solved at least.