Gemini servers need to inform clients of the
MIME type of the files they are serving. The
most convenient way for servers to figure out
the MIME type of files is via the extension
of the filename. These mappings are mostly
well-standardised (and unix systems often
have an /etc/mime.types file full of them),
but the question remains as to how servers
should recognise files to be served with the
text/gemini type defined by Gemini.
Current Gemini servers seem to use .gmi or
.gemini extensions for this purpose, and new
servers are strongly encouraged to support
one or both of these options instead of
adding a new one to the mix.
Following the convention for webservers, if a
request is received for a path which maps to
a directory in the server's filesystem and a
file named index.gmi or index.gemini exists
in that directory, it is served up for that
path.
File size
Gemini servers do not inform clients of the
size of files they are serving, which can
make it difficult to detect if a connection
is closed prematurely due to a server fault.
This risk of this happening increases with
file size.
Gemini also has no support for compression of
large files, or support for checksums to
enable detection of file corruption, the risk
of which also increases with file size.
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.
Of course, because Gemini supports linking to
other online content via any protocol with a
URL scheme, it's still possible to link from
a Gemini document to a large file served via
HTTPS, BitTorrent, IPFS or whatever else
tickles your fancy.
There should be another entry point (e.g.
@derhuerst/gemini/send) that behaves likesend.The Gemini best practices for file sharing should be respected: