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
Wuerfel21