Caching in development instance

Administrators
1

Hello everybody, happy New Year :slight_smile:

Okay so my issue probably arises from the strange setup, we got going at our institute, but I’m not sure how to best resolve it. Basically, we’re hosting a development instance of Indico from a github fork through uWSGI just like a production setup (as described in the documentation). The idea is to have a production level server where we can still make changes to the core.

In theory this likely ill-advised setup seems to work fine except for one major issue. Nothing is cached and I don’t understand why. The Indico service is running on a Debian 12 machine served by an Apache2 server (passed through uWSGI). However, if I understand correctly, the large JS bundles (such as common, react, mathjax, jquery) are served as static files by the AliasMatch Directive. So why does the Apache server never reply with a 304? When the Indico packet is installed using pip this works with the, as far as I can see, exact same setup.

Does anybody have an explanation? I suppose, the all around better solution for us would be to serve Indico from a custom pip packet. I’m just curious where this issue comes from.

Thanks in advance and best regards <3

2

Okay I have found a work around that seems acceptable. I noticed that the server response always features the no-cache field in the header. However, this is done whether Indico is installed from pip or run from the source code. If I understand the documentation correctly, the no-cache header means that the browser checks back with the server to make sure that the files haven’t changed, regardless of any other cache control (such as ETags or TTLs). My suspicion is that when run from source Indico will always tell the browser to fetch the resource which makes perfect sense for development of course. The thing I am still wondering about is where this is decided in the code but as everything is working as intended, it’s really just a matter of curiosity.

Long story, short: removing the no-cache header “fixes” this “issue” e.g., by adding Header unset Cache-Control to the Apache configuration. It also works to change the header to must-revalidate which is probably a better option.

Best regards :sparkles:

1 Like