element-web: develop.element.io not updating after clicking update

Steps to reproduce

  1. Log into develop.element.io
  2. Use it for a bit and wait for new stuff to land and/or for element to check for new changes
  3. 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)

Most upvoted comments

Clicking “Check for update” in the “Help & About” dialog says an updated version is available even after the force-reload, and even though the version in the response matches what is showing in the about dialog (1.9.6-rc.2)

The request headers were:

GET /version?cachebuster=1638789283641 HTTP/2
Host: staging.element.io
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Accept-Language: en-GB,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
TE: Trailers

and response was:

HTTP/2 200 OK
date: Mon, 06 Dec 2021 11:14:44 GMT
content-type: text/html
last-modified: Wed, 01 Dec 2021 11:53:16 GMT
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: sameorigin
permissions-policy: interest-cohort=()
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=5Hp1edU7Q%2BKsMk62MNcLR6d1TVtIlN7kKzphMpC3RWVFKYDEmV%2BFFBmYuco0gUMk269dlbkraizp7hrMT4MFZvvn3UBEkBW7DOZlF0%2BZdtEYGPiIvRIC1Gks68%2B%2BCqM9bY294VytqeFTZtCvTmiMXw%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 6b95179eccb07777-LHR
content-encoding: br
X-Firefox-Spdy: h2

1.9.6-rc.2

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

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 times https://develop.element.io/?#/... (notice the question mark). The cache-control header has the wrong value in the latter case but not the former.

Indeed, that’s returning a different header:

[10:10:15] babolivier@Noah:~$ curlie 'https://develop.element.io/?#/room/#matrix-internal:matrix.org' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: en-GB,en;q=0.8,fr-FR;q=0.5,en-US;q=0.3' --compressed -H 'DNT: 1' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: same-origin' -H 'Connection: keep-alive' -H 'Cookie: [REDACTED]' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: trailers' > /dev/null
HTTP/2 200 
date: Mon, 06 Dec 2021 10:34:25 GMT
content-type: text/html
last-modified: Mon, 06 Dec 2021 10:28:52 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: sameorigin
cache-control: max-age=691200
permissions-policy: interest-cohort=()
cf-cache-status: MISS
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=IQaRKvjvbiQyAS%2Bwe6sS%2FyhYPLHyk4eOrsPcEUQmI8zKAPYYO4cYVth1UzSzIJ7%2FyqCkB7HVqoIhaLWzeiCgSMYhOJezld65B02ZgGsrd5SaOFakEZ%2FMNWbiXr61V0P0%2BBNeqNhUuXvYCkwYdgMUFw%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 6b94dc9329be71c9-LHR
content-encoding: br

I’ve redacted the cookies in case they contain sensitive secrets, but removing them from the curl doesn’t change the cache-control header in the response.

I’ll try to tweak the line to see what makes that value change.