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
Nixpkgs patches many libraries to read certificate bundle mentioned in
NIX_SSL_CERT_FILE, and /nix/store is already present in the sandbox.
Related to https://github.com/NixOS/nixpkgs/issues/409848
ed
Danila Kamaev
yuki
shermanhlc
h3