Introduction

While working on Kristall I noticed that Gemini would also fit REST services or similar patters really well... If there was an option to upload larger chunks of data. This document is an attempt to design a simple and easy-to-use (speak: works with 'openssl s_client' by hand) extension of the gemini protocol to allow uploads of larger chunks of data.

Basic Idea

Gemini status code '10' is meant to notify the client that it expects input from the client, then closes the connection. The idea of this proposal is that the server does not terminate the session but keeps the connection open and waits for possible client input. If the client does not want to upload any data, it can just close the connection, sending nothing. If the client wants to upload data, it just sends the data, then terminates the connection.

This allows much larger data to be uploaded from the client. The current URL-based approach is limited to roughly 700 byte via base64 URL encoding, this restriction would be lifted.

Problems

This approach has two problems:

1. The server has no chance to see if a client upload was interrupted or successful, it is terminated by the closing of the connection.

I think it's acceptable to allow uploads to break, the same as downloads are allowed to break:

Quote:

For all of these reasons, Gemini is not well suited to the transfer of "very large" files. Exactly what counts as "very large" depends to some extent on the speed and reliability of the internet connections involved, and the patience of the users. As a rule of thumb, files larger than 100MiB might be thought of as best served some other way.

2. When the client has uploaded the data, there is nothing to continue with. The URL doesn't change.

This problem can be addressed by expanding the <META> portion into the following:

10 <REDIRECT_URL> <PROMPT>

<META> is split into two parts separated by a single <SPACE> character. The first part (<REDIRECT_URL>) should be handled like a status code 40 in which the client will redirect after a successfull upload. The second part (<PROMPT>) is the same as the old <META> from the original specification and must be shown to the user.

Based on <PROMPT> the user may decided *what* to upload and *if* the upload should happen at all.

Considerations on complexity

This change would clients require to keep certain connections open and some others not. Reacting to an input makes the state machine more complicated than it should be:

Original Gemini State Machine:
{Open} → {Request} → {Response} → {Close}

Modified State Machine:
{Open} → {Request} → {Response}       →      {Close}
                         \                     /
                          `-{User Query}------+
                                 \           /
                                  `-{Upload}´