[ANN] GemIF - Simple Interactive Fiction engine for Gemini

Nick Thomas gemini at ur.gs
Fri Dec 4 19:40:57 GMT 2020



On 4 December 2020 18:24:58 GMT+00:00, mbays at sdf.org wrote:
>* Friday, 2020-12-04 at 07:53 +0000 - Luke Emmet
><luke at marmaladefoo.com>:
>
>> On 03-Dec-2020 23:20, Nick Thomas wrote:
>> > On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote:
>> > > I'm not sure I'm  willing to categorically state all requests
>must 
>> > > be idempotent.
>> 
>> Astrobotany is a bit of an outlier in this respect. It can get away 
>> with "abusing" gemini links only because it sits behind a layer of 
>> authentication, that restricts access to the links within the 
>> application.
>
>Actually, this might be a good convention: we could declare that any 
>gemini request should be treated as idempotent, i.e. GETlike, *unless* 
>the server is sent a client certificate as part of the connection 
>handshake (for the original connection, in the case of session 
>resumption).

I've been mulling over this one a bit - the search engine example is very good.

Client certificates aren't the worst heuristic here, but i do see the potential for false positives & negatives.

Now we have robots.txt, we *could* say that non-idempotent requests (state-changing ones in general, really) ought to be protected in there. That ups the importance of any crawler actually paying attention to it - and my hypothetical, but spec-forbidden, eager loading client could use it to behave safely too (it could be reimagined as a local caching proxy to work around the prohibition on following links without user interaction, i guess).

This feels more appropriate to me than the client certificate heuristic, since it's *possible* for robots.txt to make conforming clients be safe 100% of the time.

/Nick


More information about the Gemini mailing list