element-web: develop.element.io not updating after clicking update
Steps to reproduce
- Log into develop.element.io
- Use it for a bit and wait for new stuff to land and/or for element to check for new changes
- Click the update button
Outcome
What did you expect?
After the tab reloads the Element Web version is using the latest commits from the element-web, matrix-js-sdk and matrix-react-sdk repos.
What happened instead?
The version string shows that it’s stuck at old commits (my current version is f496d6d5bf31-react-4a6d46b76adc-js-87b920698f4c) and changes introduced by new changes are missing.
After discussing this in internal rooms, it looks like this is caused by requests to anything under https://develop.element.io/ getting responded to with a cache-control: max-age=691200 header, whereas that header should be cache-control: no-cache to prevent any caching.
Not sending logs because that’s not an issue with the app itself but with the web server(s) involved in delivering it.
Operating system
Arch Linux
Browser information
Firefox 93.0
URL for webapp
develop.element.io
Application version
f496d6d5bf31-react-4a6d46b76adc-js-87b920698f4c
Homeserver
element.io
Will you send logs?
No
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 16 (13 by maintainers)
Indeed, I can repro this on staging - I think this is a regression caused by https://github.com/vector-im/element-web/pull/19857
Creating a separate issue at https://github.com/vector-im/element-web/issues/20058 as I think its different to this one, it’s not due to cache-control headers but rather a bug
This also applies to staging.element.io - https://matrix.to/#/!YTvKGNlinIzlkMTVRl:matrix.org/$cHj7WJ38ET2sEaEZaplNHM_Wj68GEzvlxwubV0qMEqM?via=matrix.org&via=privacytools.io&via=mozilla.org
fwiw it looks like the cause in this case is that something at some point caused Element to update the current URL of the tab with a question mark, which just stuck around. Looks like I managed to fix things by removing the
?from the URL in the address bar. Not sure what the root cause is though.aha! okay, great find - I think we’ll have to adjust the rule in Apache slightly then.
Right, it looks like in some cases the browser tries to request
https://develop.element.io/#/...and other timeshttps://develop.element.io/?#/...(notice the question mark). Thecache-controlheader has the wrong value in the latter case but not the former.Indeed, that’s returning a different header:
I’ve redacted the cookies in case they contain sensitive secrets, but removing them from the curl doesn’t change the
cache-controlheader in the response.I’ll try to tweak the line to see what makes that value change.