Samuel
is uploadblob being weird, or is it firefox? keep seeing half-corrupted image previews
2 8
Samuel
@samuel.fm
yeah same. I initially saw it on the gif previews and started panicking
1 1
David Buchanan
I've seen it aaaages go on youtube thumbnails once or twice, I wonder if it's a weird edge-case that bsky happens to trigger. Whatever it is, seems like some kinda non-deterministic memory corruption bug within the jpeg decoder which is kinda spooky.
2 4
David Buchanan
so here's a fun observation. I have a screenshot of one of the corruptions I saw. I downloaded the image and re-created the same corruptions - the first corruption at least is consistent with a ~1400 byte chunk being missing from the file!
1 1 12
David Buchanan
however, if there was a dropped packet, TCP along with TLS1.3 etc. really ought to prevent that from causing any application-level issues, so clearly there's a bug *somewhere*
2 6
David Buchanan
So I narrowed it down some more and the missing chunk is exactly 1448 bytes long, at offset 4*1448 bytes into the file. aaand guess what
2 11
Gordon Mohr ꧁🧿🧿꧂
reminds a bit of bugs I recall that were ultimately due to some malfunctioning network hardware on path between hosts – consistently losing bits in particular (often but not always reproducible) patterns with just certain remote-hosts/streams. …
1 1
Gordon Mohr ꧁🧿🧿꧂
… can *seem* like it's browser-caused simply bc diff browsers trigger slightly different response headers, and thus slightly diff packet alignments that either trigger-or-not certain 'unsendable' packets or premature stream-failures. …
2 1
David Buchanan
there's no way this isn't browser-specific, because TLS shouldn't let wire corruptions reach the client, and afaict the data in the browser's *cache* ends up bit-perfect, it's merely the first on-screen render that's borked
1 1
Gordon Mohr ꧁🧿🧿꧂
sure, & if you're *certain* local-cache correct from start – a 2nd render, even without new net-fetch, succeeds – that localizes problem even further to UI. but I've seen outwardly 100% browser-specific glitches that were actually that browser unluckily triggering weird/deep failures far away. …
1
1 more reply
Gordon Mohr ꧁🧿🧿꧂
… (so if seems: "consistently only in 1 browser", see if same browser still sufficient with (a) lower MTU or different internet uplink; (b) different request-headers; (c) forced change in request-headers that triggers some change in response headers.)
1
Ryan Castellucci 🜬
The TCP maximum segment size option is supposed to be advertising the the largest TCP payload it can accept *assuming no TCP options*. The sending host is responsible for subtracting the space its TCP options take from that.