[Bug]: Users always get the old version of the webpage

[SailFlorve]

What happened?

Users always get the old version of the webpage, when they visit host url. and only after refreshing, or visit host/c/new(may be c/new has no cache before) do they see the new version. However, the next time they visit host url, it's the old version again. This issue has persisted since an update in August.
It’s impossible to ask users to manually clear their cache or always visit /c/new. How long will it take to resolve this caching issue?

Steps to Reproduce

//

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Some measures have been taken already, make sure you're already on the latest update:

#3822
#3824

This issue has persisted since an update in August.

This may be the root of the issue: #3455

It does help with server performance, but I agree, since the project receives a lot of continual updates, the default values originally set were not ideal. I reduced the default values for these environment variables from 4 weeks/1 week to 2 days/1 day respectively.

My suggestion to mitigate is set even lower values to this, to see if it helps:

STATIC_CACHE_MAX_AGE=2 # 2 seconds
STATIC_CACHE_S_MAX_AGE=1 # 1 second
DISABLE_COMPRESSION=TRUE

https://www.librechat.ai/docs/configuration/dotenv#static-file-handling

Seems to be helping on my end.

[danny-avila]

note that you may need to refresh the first time after setting these values, but try every time after that

[SailFlorve]

note that you may need to refresh the first time after setting these values, but try every time after that

I checked the response headers for the user, and there's already a cache-control directive: public, max-age=2419200, s-maxage=604800 (which might have been included in a certain version and cached). Does this mean the user has to wait 28 days before the new configuration can be applied?

[danny-avila]

I checked the response headers for the user, and there's already a cache-control directive: public, max-age=2419200, s-maxage=604800 (which might have been included in a certain version and cached). Does this mean the user has to wait 28 days before the new configuration can be applied?

No, they just need to clear their cache. On chrome it can be done from the info button to the left of the address bar. On firefox, it is done through browser settings, under Privacy & Security tab

[danny-avila]

Those values confirm they used the app when it was serving the old default values, sorry for the inconvenience

[SailFlorve]

Those values confirm they used the app when it was serving the old default values, sorry for the inconvenience

Okay, thanks for the explanation, but unfortunately, I have no way to notify the user to clear the cache manually, so the user will have to wait for now. 😂

[marvin-roesch]

@danny-avila One of our users just ran afoul of this caching issue. We had already updated from 0.7.4 to 0.7.5-rc2, so I thought #3824 should have addressed this, but when looking at the responses delivered by LibreChat, the HTML doesn't contain the meta tags.

I'm also a little confused by the project layout, as there is both the index.html in the root directory as well as the one in client/. The latter looks like what's being delivered for us.

Lowering the static cache lifetime works, but ideally we'd have the app root be served uncacheable always.

Something else we've noticed is that LibreChat serves the client root whenever requesting an /asset path that doesn't exist. Not sure if this is intentional, but it leads to outdated spreadsheet links leading to a 200 response with text/html MIME type. I'd expect this to return a 404.

[danny-avila]

@marvin-roesch you would have to restart the backend to serve any changes made to the frontend code (after re-compiling the client code).

Can’t you make it practically uncacheable by adjusting the cache lifetime?

For a Single Page Application like LibreChat, serving the index.html file for unknown routes is a common practice, but we could make a distinction for /asset paths to return 404.

[marvin-roesch]

We're running LibreChat in a Kubernetes cluster using the provided Docker images, so we're not doing any compiling ourselves. Running the 0.7.5 Docker image, the cache meta tags are not present in the server responses. I was pointing out the two index.html files as my guess is that the wrong one was adjusted in #3824.

I have reduced the cache lifetime, but for actually long-lived assets (e.g. the hashed script or stylesheet files), having it higher again would be nice.

I certainly would expect even an SPA to serve a 404 on a path that is verifiably never going to be served by the client-side router. Returning 404s for unknown assets would be much appreciated.

[danny-avila]

@marvin-roesch I will look into it when I can. PRs welcome.

[danny-avila]

@marvin-roesch It looks like the tags are stripped but we can more robustly influence the index.html cache headers from server-side code. Made the change here, also made those response headers configurable:

#4565

I can confirm that the index.html is correctly being requested every time after the change, whereas before the browser would pull from cache with status code 304

[marvin-roesch]

Thanks for the prompt change, @danny-avila! I'll see about maybe PRing the 404 for unknown assets myself 😄