Lack of cache control headers leads to 'Failed to connect to server' when behind authenticating reverse proxy

[michaeltandy]

Hello!

I host novnc behind a reverse proxy, and when a user makes a request without the right authentication cookies, it forwards them to an auth server to get them. But I've run into a minor caching problem with this setup.

Websockify doesn't set a cache-control header when serving static files - so web browsers apply heuristic caching, and cache the HTML for several days. Everything works fine on the first load, and for a few hours thereafter.

But if a user loads novnc after their auth cookies have expired, vnc.html and all other assets are served from their cache (without revalidation) so they don't get forwarded to re-authenticate. The browser's first request is a websocket request to /websockify - to which the reverse proxy responds with a 302 HTTP redirect to a login page.

But the javascript websocket API considers this a generic failure to open a websocket; Failed when connecting: Connection closed (code: 1006) - and the user is shown novnc's ‘Failed to connect to server’ red bar.

There are a few possible fixes for this:

1. Websockify could start adding cache-control headers to static assets.
2. Novnc could try to detect and handle this situation in javascript (e.g. make a HTTP request to detect if redirection is going on)
3. I could switch to a better reverse proxy, one that can add cache control headers for me.
4. I could set the file modification time on vnc.html to the year 3000 so browser heuristic caching stops deciding to cache it (I'm trying this as a workaround)

Obviously it's debatable where this issue belongs, but novnc said cache header questions belong to websockify back in 2018 so here I am. Thanks for taking the time to read my issue! 🙂

Here is a redacted screenshot showing a wss:// request getting a HTTP 302 redirect response:

[CendioOssman]

If we added cache-control headers, then they would likely be the same as what the defaults are. Caching is a good thing. So that would not resolve your issue.

This might be out of scope of what a general solution like noVNC and websockify can provide. So you probably need to modify things for this custom setup.

A better proxy does sound like the reasonable approach. If the proxy is setting a timeout on resources in the form of a cookie lifetime, then it should make sure the cache settings match that lifetime.

What proxy is this?

[michaeltandy]

If we added cache-control headers, then they would likely be the same as what the defaults are. Caching is a good thing.

Bear in mind, the cache behaviour also applies to software updates. And if you have multiple javascript files they can get cached differently, leading to weird behaviour. That's why some folks rename all their javascript and css files on every new deployment, a practice known as 'cache busting'. Of course, over-enthusiastic caching is much less of a problem if you're not rolling out updates very often.

If your preference for caching is because your files are big, I believe you can use must-revalidate and the browser will make an if-modified-since request - you get the delay of a round trip to the server, but save the file transfer.

A better proxy does sound like the reasonable approach.

As a workaround, I just set the mtime on vnc.html to the distant future, which disables the browsers' heuristic caching.

What proxy is this?

I'd rather not name names, but it's a corporate "zero trust identity-aware proxy" - and like most enterprise software, it's sold to CTOs not users.