💾 Archived View for rawtext.club › ~sloum › geminilist › 002243.gmi captured on 2020-11-07 at 02:46:35. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

New user, spec details

kooda at upyum.com kooda at upyum.com

Fri Jul 17 20:39:16 BST 2020

- - - - - - - - - - - - - - - - - - - 

Hi!

I’ve been browsing the Gemini space for about a week and so far I loveit! I just fired up my own server and intend to contribute to the contentsoon.

I also skimmed the mailing list and there are still a few details of thespec I would like to discuss:

First, in the overview of the transaction (#1.1), it appears to me thatthe client must wait for the server to close the connection before doinganything with the response. It seems to be an unnecessary constraint,especially since the text/gemini format is designed to be handled line byline without needing to store the whole document. It would also enablerendering of progressive images, playing audio files, etc during thetransfer.

In the same section, as well as #3.3 Response bodies, it is stated thatthe server closes the connection after the document is sent. I think itwould be interesting to be a little more precise and state that the serversends a close_notify from the TLS layer before closing the connection. Itwould make it possible for clients to detect a truncated download and warnthe user about it.

I would also like to know the general opinion about TLS session caches. Itcould be used as a light tracking tool… but I don’t think it’s thatbad. IP address and requests timing can also be used in the same way totrack users on a single server. And if someone really wanted, they couldjust serve unique URLs to each visitor to track their movements on theirserver.