"Wide load" status code(s)?

[solderpunk]

On Wed, Jun 10, 2020 at 08:04:54PM +0100, Luke Emmet wrote:
 
> If we can
> have lang and mime-type in the response for 20 response, is it really that
> philosophically disturbing to include this important information that we
> know makes network bandwidth negotiation better for everyone?

Important distinction: we don't have lang *and* MIME type, we have MIME
type.  The text/gemini MIME type has a lang parameter defined.  We're
allowed to define parameters on text/gemini because it's our type (we
can't prescribe parameters on any other text/* type, which by the way is
the answer to some of the questions in
gemini://mozz.us/journal/2020-06-08.gmi).

Adding a content-size parameter to text/gemini *is* deeply
philosophically disturbing because MIME types are, well, *types*.
Categories.  It makes no sense whatsoever to put details specific to a
particular token as part of type declaration.

So the only way to add an analogue of content-length would be to send a
MIME type *and* content-length, and then we need some kind of delmiter.
For the sake of argument, let's say a tab character.

So you send <MIME><TAB><CONTENT-LENGTH> and then, boom, next week it's
<MIME><TAB><CONTENT-LENGTH><TAB><SOMETHING-ELSE>, and it never stops.
Exactly one parameter is a stable, defensible position (what Gemini has
now).  Arbitrarily many delimited parameters is a stable, defensible
position (what the web has now).  Anything in between is at very real
risk, IMHO, of mutating into the latter over time.  Once a delimiter
comes along, it's impossible to stop subsequent expansions.
 
> If we have to, I think it could be a client option:
 
> [ ] limit non-text content to 5Mb per request
> [x] download all text/* content

Well, this second option is actually already totally possible.  As far
as I know, it's not implemented by anybody yet.  I kind of like the
idea, I may add it to AV-98.

Cheers,
Solderpunk