[fix] uwsgi: don't set static-expires #4436
Conversation
As long we don't have a working solution for cache busting [3][4] we should not set an expire time in thw uWSGI config. The default procedure in every web browser is the "304 Not Modified" [2] and this default procedure should also be sufficient for us as long as we have not implemented a complete alternative (cache busting) / form [1] > By default uWSGI will add a Last-Modified [2] header to all static responses, > and will honor the If-Modified-Since [2] request header. [1] https://uwsgi-docs.readthedocs.io/en/latest/StaticFiles.html#setting-the-expires-headers [2] https://developer.mozilla.org/de/docs/Web/HTTP/Status/304 [3] searxng#4433 [4] searxng#964 Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
|
Please wait before merging this PR, some context is required. |
|
As far I remember, I might be wrong With the docker imageThe static files are served by UWSGI. ==> Line 52 in 8984d7a and works together to provide a nice speed boost. No docker, no configuration about the static fileIn this scenario, there is a reverse proxy but the static files are served the Flask application. In this case Markus, you may think ok this is not the standard installation, so this is not supported. However, I think a lot of existing installations are configured this way (static files served by the Flask application). Perhaps it is possible to "fix" the Flask application, but I'm not sure this is right way. The recommended way I see is URL like this |
Sure? .. As far I remember the However .. as long we set: Line 52 in 8984d7a in our installation methods, we have a bug when
I fully agree with ..
If we have fixed the URL, then we can activate But before it isn't fixed and cache busting is not the default we should not set
This PR is just a interim solution to get static files updated on our clients, which is currently not the case on some installations that using the SearXNG defaults from |
|
I merge this PR / it gives us time to look for: |
Cache busting has caused serious problems for users in the past, here are two examples: - searxng#4419 - searxng#4481 And it makes development and deployment significantly more complex because it binds the client side to the server side: - searxng#4466 In the light of a decoupled development of the WEB clients from the server side: - searxng#4988 is it appropriate to abandon this feature. In fact, it has been ineffective since searxng#4436 anyway. However, the benefit has always been questionable, since at best only a few kB of data are saved (at least in the context of an image_proxy, the effect is below the detection limit). Ultimately, the client is responsible for caching. Related: https://github.com/searxng/searxng/issues?q=label%3A%22clear%20browser%20cache%22 Closes: searxng#4466 Closes: searxng#1326 Closes: searxng#964 Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Cache busting has caused serious problems for users in the past, here are two examples: - #4419 - #4481 And it makes development and deployment significantly more complex because it binds the client side to the server side: - #4466 In the light of a decoupled development of the WEB clients from the server side: - #4988 is it appropriate to abandon this feature. In fact, it has been ineffective since #4436 anyway. However, the benefit has always been questionable, since at best only a few kB of data are saved (at least in the context of an image_proxy, the effect is below the detection limit). Ultimately, the client is responsible for caching. Related: https://github.com/searxng/searxng/issues?q=label%3A%22clear%20browser%20cache%22 Closes: #4466 Closes: #1326 Closes: #964 Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
As long we don't have a working solution for cache busting [3][4] we should not set an expire time in the uWSGI config.
If we have changes to the CSS or JS files, these are not yet transported to the client by default, which causes problems and irritations on the client side [3]:
label:"clear browser cache"The default procedure in every web browser is the "304 Not Modified" [2] and this default procedure should also be sufficient for us as long as we have not implemented a complete alternative (cache busting) / form [1]