Caching and sizes, the explosion of responise codes (was Re: Caching and status codes)

[Sean Conner]

It was thus said that the Great Philip Linde once stated:
> 
> The overflowing of 2x code resulting from a combinatorial hell is
> entirely self-inflicted through your choice to ignore this aspect of
> the existing specification.

  I don't agree that this is self-inflicted on me---what I'm trying (and
failing) to point out is that adding mroe success calls *could* lead to 
combinatorial hell.  HTTP already has 10 success codes in the 200 range, and
none of them relate to caching status (since caching status is passed along 
in headers).  Granted, none of the HTTP success statuses (with the exception
of 200, which is mapped to 20 in Gemini) apply to Gemini, but in another
universe where HTTP *did* have separate success code for caching
information, I can see some combinatoric increase, say for 204, 205 and 206
with nothing said, cache and no-caching of results (that's nine new ones   
right there).

> I've already suggested to you a way to avoid this (use a different 
> first digit). 

  No, that was to prisonpotato at tilde.team---they were the first to come up
with the idea, not me.  I just implemented it first (much the same way I
implemented the first Gemini server even before solderpunk did [1]).  Also,
the size breaking code is only active on one link on my site, not everwhere.

> This additionally avoids having to rewrite 3.2 of the
> spec and invalidate existing clients that take for granted that "the   
> first digit alone provides enough information for a client to determine
> how to handle the response".
> 
> Moreover, with TLS already having a mechanism to signal the intended
> end of a connection, I don't think that content size is a pressing
> issue. It would allow for download progress bars, but adds nothing
> over TLS in terms of ensuring that the content is fully received.

  The concern is over large responses.  It wasn't much of a concern until
gemini://konpeito.media/ was created and serving up large audio files (and
archives of said audio files).  I can envision a client being configured to
abort the download if say, a 10 megabyte file is being downloaded.  It
*sucked* when my DSL went down in late September/early October (yes, about
three weeks) and I had to rely upon my cellphone hot spot.  I didn't have a
large data plan for the cell phone becuase I didn't need it, until I did. 
It would have been nice to configure my web browser to not download anything
over 5M at that point.

  -spc

[1]     I did it completely ignoring the status codes defined at the time,
        because I felt they were too limiting (single digit).  It took some
        back and forth, along with a few other implementations (that did
        follow the spec), before the current two-digit scheme was defined.