"Wide load" status code(s)?

[Koushik Roy]

Sorry replying to the list address this time...

How about letting the server decide? I can imagine a scenario where the 
server defaults to sending text/* mime types as 20 responses and 
everything else as 21 responses. Then servers can let configuration or 
(s)CGI output determine how to decide on 20 vs 21. While leaving it up 
to the server is subjective, I think most content authors understand 
whether something is meant to be quickly digested and rendered or 
whether something should be downloaded/queued/status line shown.

- meff


On 6/10/20 12:32 AM, solderpunk wrote:
> Hey all,
> 
> Just throwing out a quick idea I had last night while trying to sleep,
> to see how people feel about it.  It's simple and easily ignorable and I
> think it's kind of neat.
> 
> It's been a small pain point for some people for a while now that there
> is no way for a Gemini client to know how large a file it's downloading
> is without simply downloading the whole thing.  This is inconvenient
> from a UI perspective, as there is no way to display a progress bar, and
> simple clients like AV-98 which simply download a complete file and then
> pass it off to a handler program appear to "freeze" on large downloads
> with no clear indication that anything is happening.  This is a much
> bigger problem for people on limited machines (e.g. low memory diskless
> systems are perfectly viable for reading text/gemini content and
> displaying small images but not for downloading large binaries, but they
> can't gracefully opt out of the big stuff and are forced to simply
> terminate the connection once a threshold amount of content has been
> downloaded, and then wastefully discard that partial content) or
> internet connections (e.g. people at sea using satellite data plans
> which are billed per megabyte).
> 
> People usually want to address this by having the server somehow declare
> the file size upfront in the header, as per HTTP's "Content-Length", but
> I've resisted that tooth and nail because there's no sensible way to do
> it which doesn't turn the response header into an infinitely extensible
> thing which people can tack their own variables onto, leaving us no
> better off than HTTP (so, please, no more ideas on this front)...
> 
> I was very happy to realise that a lot of these problems can be solved,
> or at least ameliorated, in a very simple way with an additional 2x
> status code.  Since I plan to deprecate the current 21 code for ending a
> transient certificate session, we could reuse 21 to mean "SUCCESS, a
> response body follows, and it's larger than $THRESHOLD MiB" (note I am
> proposing no change to the existing code 20 - 20 does NOT mean "what's
> coming in less than $THRESHOLD").  Simple clients could simply treat 21
> as 20 and be in exactly the situation they are in now, so the graceful
> degredation of status codes to their x0 form works nicely here.  But
> e.g. AV-98 could print "Downloading large file, please wait..." upon
> receving a 21, and then proceed as usual.  This is a very low effort
> client change, but it solves the problem of people thinking something
> has gone wrong when they unknowingly start a large download.  More
> importantly, users in resource-limited environments could use clients
> which simply terminate the connection immediately on seeing a header
> starting with 21, providing a quick and low-waste "opt out" of large
> content.
> 
> On the server side, again, a dirt simple server could just always serve
> up 20 without actually breaking anything.  I realise that knowing
> whether to use 20 or 21 for dynamically generated content may not be
> straightforward - no problem, it is *always* valid to just send 20 when
> in doubt.  21 is nothing more than a helpful hint to clients who might
> need it.  It doesn't need to be 100% reliable to still have value.
> 
> This feels like a good idea to me.  It's totally optional and very easy
> to handle on both the client and server sides, and I feel like being
> friendly to small/slow computers and slow/intermittent network
> connections is a good fit with the overall "vibe" of Gemini, provided
> doing so does not conflict with overall simplicity.
> 
> Naturally, deciding to do this will lead immediately to a weeks-long
> heated debate on what the appropriate value of $THRESHOLD should be.  We
> *could* wade into those waters, but I'll just also throw out that we
> could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> 100MiB respectively and leave it at that.  Clients targetting
> resource-limited environments could let their users configure their own
> threshold for early termination of downloads.
> 
> Cheers,
> Solderpunk
>