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

[Sean Conner]

It was thus said that the Great khuxkm at tilde.team once stated:
> November 8, 2020 12:18 AM, "Sean Conner" <sean at conman.org> wrote:
> 
> > I have my own ideas about caching, but I want to cobble up a
> > proof-of-concept first before I talk about it more, because from where I
> > come from, working code is worth more than talk.
> > 
> > -spc
> 
> Speaking of cobbling up proof-of-concepts, I've created a proof-of-concept
> of how I feel these cache-hint success codes would work:
> 
> https://gist.github.com/febd3f5ae2308e8b55449a92c6e58a65
> 
> (Yes, I know it's on GitHub, but I have a shell script to make Gists from
> the command line and so I want to use it.)
> 
> This includes a spartan client (it literally just spits the raw protocol
> response out at you) with caching behavior influenced by 21/22 (in
> practice, it caches all 2x responses except for 22 responses), as well as
> examples of endpoints to hit that return each code.
> 
> Hopefully my working code will prove my point better than I could in words.

  And I have my "proof-of-concept" up at well.  It's at

	gemini://gemini.conman.org/test/testcache.gemini

  My approach is a bit different, probably a bit harder to implement server
side, but deals not only with the caching issue, but with repeated requests. 
I'm not sure how popular it will be, but hey, it's out there, and it only
adds one general purpose status code (23 for now) that means:

	okay, request was okay, but there is no data to serve you.

  How it works:  A plain request:

	gemini://gemini.conman.org/test/cachefile.txt

will always return the content.  However, if you include a timestamp using a
path parameter (which is *NOT* the same as a query paramter, and is in the
ISO-8601 format):

	gemini://gemini.conman.org/test/cachefile.txt;2020-11-08T00:00:00

If the file is *newer* than that timestamp, you get the normal response of
20 and all the content; otherwise you get a response of 23 (with the normal
MIME type) and no content, meaning it hasn't changed since the given date.

  This means a client that doesn't with to deal with caching at all will
never see any difference.  A client that does, or (in the case of feeds) not
want to always download content that hasn't changed, can do that as well.

  -spc