💾 Archived View for rawtext.club › ~sloum › geminilist › 005523.gmi captured on 2023-11-14 at 10:02:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Katarina Eriksson gmym at coopdot.com
Tue Feb 23 17:16:59 GMT 2021
- - - - - - - - - - - - - - - - - - -
Mansfield <mansfield at ondollo.com> wrote:
I've been experimenting with a non-standard status code and I wanted to
share some details. I am running this experiment to find a way for users to
manage content using only a Gemini client and server. No ssh, rsync, vim,
emacs, nano, or anything else.
A gemini client could implement an existing protocol, like rsync or sftp,to achieve the goal of not requiring any additional software to manage acapsule.
The simplest conceptual adjustment is that there's no character limit on
the input a client might provide in request/response input cycle involving
a status code of 12. Status codes 10 and 11 have specified limits around 1k
bytes (I'm fudging the details there). Status codes 10 and 11 also have the
specified behavior of putting the user input into the URL as the value of
the query component. So... the simple part is that there's no limit to the
number of bytes sent from a client to a server in a request/response input
cycle involving a status code of 12.
So you are using status code 12 to signal the client to use a differentkind of request. What happens when a client interpretes that as a statuscode 10? (As it should if it doesn't understand 12.)
To escape the 1k limits of the URL in responses to 10 and 11, my
exploration of status code 12 places the user input in the body. This meant
I had to change my server from only understanding how to process the single
request line of standard requests to processing the request line *and* the
body when it sees a response to a 12. So I needed to tell the difference
between requests with a body and ones without.
Introducing a new kind of request into gemini would be a mistake, I think.We have seen proposals for side protocols on this list to fill this spacebut they didn't get popular.
Since I then needed to be able to tell the difference between requests that
didn't have a body and those that should, I modified the server to provide
unique links to the client. These unique links use a UUIDv4 that is tracked
on the server and expire after a day.
Such links could also start with something like "gemini+edit://" so thatonly clients supporting this feature can access it.
[1] - After creating an account you'll get a status code of 20 in response,
with unique links as described above - if you use those links you'll get a
status code of 12 containing the current value of the resource as the body
of the response and letting you manage your content as this email describes
(assuming your client supports sending requests with a body).
Ah, so the client only get status code 12 if it has an account. I missedthat the first time I read through your e-mail. I also missed that itsupports editing of existing text.
Ah... and another point... how does the server know when to stop reading
the body of a request that pairs up with a 12? Well... there's a deadline
on the connection. You'll want to get all your data across before then. We
don't really like that that's all we have... we've thought about
implementing something more, but other options currently feel just as
arbitrary... some max byte size?
TLS close_notify from the client maybe?
I think the simplicity of only having "<URL>CRLF" requests outweighs anybenefits we get from this approach.
-- Katarina
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/a538a9f9/attachment-0001.htm>