seemingly as of iOS / macos 26.1, safari started requesting
favicons -- specifically only favicons -- with the incorrect
browser context (they probably forgot to initialize something)
instead of the correct user-agent, it would send:
* iOS: NetworkingExtension/8623.1.14.10.9
* macos: com.apple.WebKit.Networking/21623.1.14.11.9
further, it would NOT send any SameSite=Strict cookies,
which the session-cookie is (for good reason)
putting these two together, safari now looks like a webdav client,
and copyparty sends the only appropriate response (http 401),
resulting in a basic-authentication popup
left with no good options, this is what we can do to mitigate:
* add a new option --ua-nodav which is a regex of user-agents
which are definitely not webdav clients, as macos-finder still
flipflops between WebDAVLib/1.3 and WebDAVFS/3.0.0 like normal
* use the "js=y" cookie as another flag that this is a webbrowser
merry christmas
some reverseproxies do not include a compatible alternative to
x-forwarded-proto by default, while also lacking the option to
set custom headers
add --xf-proto-fb to set a fixed protocol to assume
inlines css in msg.html to remove a roundtrip; response now requires
multiple tcp-packets but probably always did realistically (https)
Co-authored-by: stackxp <tillijungblut@gmail.com>
Co-authored-by: ed <s@ocv.me>
previously, would crash on startup if chpw.json exists and is blank,
because valid json was enforced
now allowing a blank initial file to match the behavior of sqlite
"date" is reserved for the last-modified-timestamp of each file
if extraction of the audio metadata property "date" was enabled
(not default), this would have collided; rename the audio prop
discovered thanks to #1053
also closes#1053, a PR which inspired this commit heavily
(slightly different approach for flexibility and performance)
Co-authored-by: Dawson Jeane <dawsonmjeane@gmail.com>
uploading a folder named COMPLE:X into exfat on linux would fail
because exfat behaves like windows, rejecting <>:|?*"\/
this would also fail on windows, but then due to
sanitize_fn being overly aggressive
fix this by detecting filesystem traits on startup and
also translating vpath early on windows
plus these fixes:
* adds a previously missed libvips optimization,
giving much smaller files at the same quality
* try to align the quality-scale of each backend
(pillow, libvips, ffmpeg) by filesize
