* make sure server_port headers are properly set in reverse proxied scenarios
* overwrite request and response classes to
* always apply reverse proxy environment changes (so far missing for tornado
context)
* strip cookie name suffixes from cookie names on requests and
* be sure to set cookie name suffixes for cookie names on responses
* include script root in path used for cookies
* some minor refactoring in octoprint.server setup routines
* removed ReverseProxied class (didn't work for tornado context)
* add unit tests for the whole reverse proxy, request and response customization
* Sponsors => Supporters
* Links to individual About dialog tabs from start page
* Slight rewording here and there
* rel="noopener noreferrer" for external links
* persistent notification on ongoing timelapse render job (#485)
* non-colliding timelapse snapshot name generation to not delete
existing snapshots when new print starts and timelapse has not
yet been rendered, also only delete snapshots if timelapse rendered (#318)
* list of unrendered timelapses, with option to delete files
or to render timelapse
That way people will not see connection failed messages while the server is
still starting up.
Served intermediary page als "pings" an image on the backend to detect if
a) the backend is still responding at all ("intermediary.gif") and b) whether the
server has fully started up ("online.gif").
If the backend stops responding for 5s, a message is output that tells the user
that something went really wrong and to please check the log file.
Once the server becomes online, the intermediary page reloads/switches to the
actual UI.
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 change should make sure that only those settings actually make it into config.yaml
per plugin that do differ from the default settings. Up until now the full dictionary as received
e.g. from the REST API was saved, regardless whether it contained (only) default values or not.
That led to a lot of "null" entries in the config.yaml file, which for one looked horrible and also
led to problems when a plugin actually wanted to change its default values.
With this commit, two things are done. One, upon saving a configuration the default
implementation of the save routine in the settings plugin now first diffs the new data against
the defaults and only saves what is different. Two, upon server startup a cleanup method is
now called on settings plugins whose default implementation fetches the current data stored
in config.yaml, diffs that against the defaults and only writes back the diff result. If that is empty
the entry is completely deleted from config.yaml.
(cherry picked from commit d70fe32)
At least if necessary (added new boolean flag to the constructor of
LargeResponseHandler for that). While at it also rename UrlForwardHandler
to UrlProxyHandler (it does not forward, it proxies) and make it aware of
ETag and Expires headers.
Even if the webcam URLs and the FFMPEG path is not yet configured. Otherwise
setting those URLs and the path will require a restart of OctoPrint to enable properly -
that's overkill.
(cherry picked from commit 1425b20)
If re-creation of the folder fails due to an access error, perform three retries. It might
be caused by the folder being open in the file explorer. Waiting a bit before retrying
seems to do the trick.
See also #1019
(cherry picked from commit a43de42)
Two changes:
* Asset existence will now be checked before they get included
in the assets to bundle by webassets, logging a warning if a
file isn't present.
* Monkey-patched webassets filter chain to not die when a file
doesn't exist, but to log an error instead and just return
an empty file instead.
(cherry picked from commit 2a5ec33)
Some underlying file systems might not trigger change events (e.g.
mounted remote file systems). Added a feature flag to allow for
switching to a (less performant) polling method.
(cherry picked from commit f2df174)
That way plugins don't need to implement the SettingsPlugin mixin in order to access their data folder, which is now an injected property in OctoPrintPlugin. Plugin authors should still always use the getter since that will also make sure the folder actually does exist (lazy creation).
PluginSettings.get_plugin_data_folder has been marked as deprecated.
Introduced new callback for settings plugin to hook into the point after the settings have been migrated since the initialize method is not suitable for that as it might be called before other plugin implementations reachable through hooks are initialized.
OctoPrint will take care of calling a migration function on the plugin if the plugin demands a newer configuration version than currently stored in config.yaml.
This is to make sure that they all end on a ; and hence stuff doesn't break if a file included directly after starts with a (...) construct. Of course it would be better if all bundled files are valid in that matter, however since we can't enforce that, we'll add this slight overhead to reduce the risk of stuff breaking.
See for example: http://stackoverflow.com/questions/20307462/js-cant-combine-lib-files
