The bug only manifests if a user had installed 1.2.16 earlier and never once hit "Save" in the
settings before attempting to update to 1.2.17. With 1.2.16 the updater script and settings for
OctoPrint's own update mechanism were changed to prefer "checkout_folder" instead of
"update_folder". In earlier versions however "update_folder" was still used. Saving settings
even once (even without any changes!) will migrate the data. But if that's not done a
KeyError will be raised when trying to retrieve "update_folder" from the check config, with
"checkout_folder" as its fallback.
Rather stupid error really.
Filter toggling didn't remove the specific filter but always the last item
in the filter list. No, I don't know either why I didn't notice this earlier m(
If a content type header was present on a multipart form data part it would turn
the rewritten body into a unicode instead of a byte array, causing a later conversion
to a byte stream to not capture.
Fixed both the fact that the rewritten body would turn into unicode by making
sure the content type header was provided as byte array and fixed the byte stream
conversion to also trigger on unicode instances.
Solves #1531
Only keep the cache keys, but that way we know when
we were going to cache something and then didn't
due to environmental factors, e.g. headers on request
or response.
Necessary to be able to track if the preliminary caching
has been done during startup to properly reflect that
on cached.gif
Was marking the config as dirty just when printerParameters entry existed,
which always exists - various sub entries of that are what needs to be checked
instead.
Example:
* both "session" and "session_P5000" cookies available: "session" value from "session_P5000"
* only "session" cookie available: "session" value from "session"
* only "session_P5000" cookie available: "session" value from "session_P5000"
Also added API docs regarding header encoding, incl support for RFC 5987
for filename fields in Content-Disposition headers in multipart/form-data
parts, incl. an example of an upload request with a utf-8 encoded filename.
Solves an issue with clients encoding filenames in multipart
headers in ISO-8859-1, causing an HTTP 500 response code.
This change makes ISO-8859-1 encoded headers work, sends
a 400 Bad Request instead of 500 Internal Server Error if the
request multipart headers cannot be decoded as either UTF-8
or ISO-8859-1, defines UTF-8 content type for multipart text
fields in rebuilt body and also adds support for RFC 5987 for the
multipart file upload "filename" header component.
* 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
We can't rely on the publication date anymore with the introduction of prerelease
channels, since e.g. a current devel prerelease might have been published
earlier than the latest stable but should still be considered the latest release for
this release channel
