workaround for iPhone bug in
iOS 18.6.2, 26.6, 26.6.1, ...
safari devtools has the full response,
it just never bothers calling xhr.onload
and xhr.readystate is unusably racey
(final value is any of 1..3)
motivated by a bug-report that couldn't be reproduced and
also didn't make sense, a "hallucination" as they call it?
(was submitted by an autonomous bot or something, man)
so this should make no difference aside from removing footguns
previous behavior:
* when a chunk already existed on the server, it would
unstitch and continue retrying each individual chunk
* upon unknown-wark (file already completed), it would
upload the remaining scheduled chunks before bailing
the unknown-wark behavior was accidental bullshit
the chunk-exists behavior was intentional, assumed optimal for
preserving tcp window-scaling, just not when running behind a
bufferbloating reverseproxy which may disconnect the client on
a timeout before the response is delivered, and "some clients"
still follow rfc2616-8.2.4 (retries the POST, wtf...)
wasting bandwidth + maybe further worsening conditions
"some clients" is specifically firefox with the devtools not open
another firefox joke is that it doesn't read the server-response
if the server does not drain the request-body; we end up in
xhr.onerror with no idea why, must assume the worst
new behavior:
in both scenarios, drop all scheduled chunks to be uploaded and
redo handshake, to as far as possible avoid retransmissions;
firefox will still eagerly retry 4 times but whatever
u2c was/is fine; nothing to be done
depending on network conditions and physical distance, this MAY
result in lower total speed, but the average case is likely a
net-positive, wasting less bandwidth on retransmissions,
in exchange for resetting tcp window-scaling
previously shelled out to system32/fsutil.exe; expensive and
pointless since all it does is call DeviceIoControl (ioctl)
this is not a security fix; just like most software on windows,
copyparty is still vulnerable to DLL hijacking, so this change
makes little-to-no difference security-wise; commit bb40804f2d
plus, the default config (sharing current folder read-write
without auth) was meant to be obviously insecure, intended for
quick shares on a small LAN rather than untrusted networks
famously, windows prefers cwd when resolving a binary to execute,
rather than a predefined PATH like linux / unix / every other OS
even worse, it also does this for DLLs, and mitigating *that*
is infeasible because it depends on variables we dont control
print a warning in case someone is unaware of this
the ui would still show the option to grant write-permission
when creating a fileshare; pointless since an existing file
can't be overwritten without the delete-permission
while this is obvious and nobody would intentionally create
a fileshare with write, avoid any confusion by hiding it
use libvips as last resort due to risk of OOM; example:
libvips defers to imagemagick for animated avif, and imagemagick
probably does an identify, iterating through each frame, itself
consuming 100+ MiB RAM, which libvips amplifies to 7+ GiB
similar behavior is observed with `identify a.mkv` in a shell
ed
