"Wide load" status code(s)?

[Tadeusz Sosnierz]

2020-06-10 12:36 GMT+02:00 Natalie Pendragon<natpen at natpen.net>:
> What I feel less excited about is the specification of a hard-coded
> $THRESHOLD. It feels like a magic number that's not going to fit all
> situations well - adding three of them like you brought up at the end
> improves the situation, but nevertheless still feels like a magic
> number solution. And depending on how future-proof you want these
> $THRESHOLDs to be, no matter how good the magic numbers are today, as
> years pass and internet access/quality across the world changes, for
> better or worse, the magic numbers will become more and more out of
> date.

I feel the same way; sounds like no matter what you pick will become the
"64 kilobytes" of tomorrow's jokes. And ultimately it doesn't allow the
introduction of a meaningful progress indicator. Is 100MBs a lot? Is it a long wait?
I don't know, is the upstream server fast? Is my wifi having a good day?

The alternative is tricky to come up without making the response structure arbitrary
and complex. Here's a take though: anything bigger than a megabyte or ten is realistically
not going to be text, or anything text-like that can be displayed inline. I can think of images,
videos, maybe PDFs or just a bunch of encrypted data in the form of whatever.
I wonder if it'd make sense to have a status code that indicates
“mimetype is basically meaningless, it's a big whatever,
so I'll give you the content length instead“.

Client could then choose to receive a few more bytes and check a magic byte for something
it recognizes – or just prompt the client saying “that's not exactly something we can display anyway,
(how) do you want it saved?”

--
tadzik