Framework: Heartbeat should respond 404, not 410, when session expired

[vaadin-bot]

Originally by @jdahlstrom

---

HeartbeatHandler currently sends 410 Gone if the session is expired. This is arguably semantically wrong, as a user agent is within its rights to assume that the resource uniquely identified by the URI (and only the URI - cookies don't matter) will never be available again and any future requests to the same URI should not be made. A 404 Not Found should be returned instead.

---

Imported from https://dev.vaadin.com/ issue #12526

[vaadin-bot]

Originally by @Artur-

---

Or maybe 403 (forbidden) instead. 404 is easily confused with a server configuration problem.

[vaadin-bot]

Originally by _sre_

---

I would also recommend to change 410 to 403. We have a lot of problems with the PublishedFileHandler, because the browser (at least Chrome) caches 410 responses. Now, if you have some parts of your widgetset rely on jquery or other javascript libraries, sometimes the cached 410 is returned even after a new session has been created, which lets some of your widgets just disappear. The same happens sometimes for a login iframe connector resource.
We use Vaadin Push, probably this contributes to the problem.

Another problem (which I suppose cannot be solved with websockets): There are also cases that http 404 is returned for the /PUBLISHED files:

• Establish a UI with websocket
• Delete the browser cache and cookies - the websocket connection still exists
• Next request tries to load a /PUBLISHED javascript, the request establishes a new session, but the published files were not initialized yet, because getInitialUidl was not called for this session, so it gives 404

[stale[bot]]

Hello there!

It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

[Emmenemoi]

This cached headers following a 410 on /APP/PUBLISHED/* is a real problem for loading js: there's no error (session exists) but scripts are not loaded because of 410 being cached.

This still exists in 8.5.2.

[mvysny]

I agree with changing that to 403, maybe with an error message of "no session" or such. Anything else than 410 GONE PERMANENTLY (since that's clearly not the case).

The workaround is to move .js files to the VAADIN/ folder and using vaadin:// URLs to reference them.

[edler-san]

403 would be semantically wrong as well since no authorisation takes place. 404 is the right code. As per RFC: The 404 (Not Found) status code indicates that the origin server did not find a _current_ representation for the target resource (emphasis mine) - which is exactly what happens.

I think more relevant would be to add response.setHeader("Cache-Control", "no-cache"); to handleSessionExpired in
https://github.com/vaadin/framework/blob/master/server/src/main/java/com/vaadin/server/communication/HeartbeatHandler.java

[ffdybuster]

This actually caused random session expired messages in our Vaadin 7 apps with Safari (macOS). One way to reproduce: start a Vaadin 7 app, wait until the session expires, then reload the page, log in, and wait for the next heartbeat. It will be the cached 410, resulting in a session expiry shown in the client, while the backend still has the session.

(Also, as commented in #11556, I think the current fix for this isn't perfect since it removes the session expiry message when it would correctly appear as well.)