[SPEC] Experimenting with a status code of 12

[Katarina Eriksson]

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 a
capsule.

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 different
kind of request. What happens when a client interpretes that as a status
code 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 space
but 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 that
only 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 missed
that the first time I read through your e-mail. I also missed that it
supports 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 any
benefits we get from this approach.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailing-list-archive.gemi.dev/www/attachments/20210223/a538a9f9/attachment-0001.htm>