UI + assets should actually have ETag and LastModified headers and proper
IfMatch handling on the server side and hence the server should do the
right thing on its own.
That should improve performance tremendously.
Both ETag and LastModified depend on all files the template rendering
depends on. If any of the depended on files changes, both values will
change as well. That allows us to track whether our cached copy is
still current (and force a refresh if not) and also process IfMatch request
headers and reply with a 304 directly so that we do not even have to
transfer the data if nothing changed and the browser still has it.
Also now tracks timestamps of last access to a preemptively cached
resource and cleans up stuff that hasn't been accessed in a while (7 days
by default)
Introduced a @preemptively_cached decorator that for decorated views
persists the provided data in ~/.octoprint/data/preemptive_flask_cache.yaml
in a list indexed by the view's path if the data is not yet part of the list.
During initialization the server will iterate over the persisted paths and data
and for each persisted path and entry in the list initialize a temporary WSGI
environment based on the data (which is interpretated as keyword arguments
to werkzeug's EnvironmentBuilder) which will then be used to call the view
function in the correct context.
The current implementation for / and /i18n/<locale>/messages.js utilizes
that decorator to allow preemptive caching of those views (/ being probably
the most expensive one in the whole core application) utilizing request base URLs
(internal access, external access, reverse proxy with prefix url etc) that had been
encountered in the past.
Through the new config setting server.preemptiveCaching.exceptions it is
possible to define a set of base URLs to never cache. Preemptive caching can
be globally disabled by setting devel.cache.preemptive to false.
This way we create separate caches for URLs access via different schemes/prefixes/etc.
Otherwise our generated page might not work when accessing OctoPrint from external
after accessing it from internal once.
Otherwise the GCODE Viewer will get stuck "half way through" if
"sync with progress" is enabled but the tab/browser tab loses focus
during printing and only regains it after the print has finished.
This might help with #1065 if indeed is related to background tab suspending behaviours in
browsers, but is a completely blind guess at this point since I still have not been able to
reproduce that issue myself.
Backported.
(cherry picked from commit 720cdad)
While at it also adjusted highlighting so that the folder containing
the currently selected file will be highlighted if the selected file is
not within the current folder but in one of its sub folders.
This might help with #1065 if indeed is related to background tab suspending behaviours in
browsers, but is a completely blind guess at this point since I still have not been able to
reproduce that issue myself.
