File size issues

Two quick points with regard to the fact that Gemini currently does not
convey file sizes to users at any point:


  way for a client to know whether or not a download completed
  successfully or was interrupted due to an accidentally dropped or
  even a maliciously severred connection


  with interest, who is concerned about Gemini clients with limited
  system resources unwittingly downloading large files (such as PDFs of
  scanned documents) which they aren't even capable of opening.  While I
  quite like the idea of Gemini being friendly to low-end systems, I do
  wonder whether or not the TLS requirement makes this a little moot.

Anyway, the question is do we want to change anything to address these
issues and if so how do we want to do it?

I'll quickly note in pasing that both of these problems also exist in
exactly the same form for Gopher, but I've never once heard Gopher users
complain about them.  Which isn't to say we should cheerfully ignore
them, but it does establish that they cannot reasonably be considered as
fatal flaws.

One possibility, as proposed by Sean, is to add file size to the
response header, with it optionally appearing after the MIME type.  I'm
not hugely fond of this myself, simply because it complicates parsing of
the response header.  Remember that the MIME type can have multiple
components specifying encodings etc.  If you just split the META part of
the header on whitespace, the number of components is variable, so
recognising whether or not an optional filesize is present requires
actually inspecting the parts and looking for a number.  In fairness to
Sean, at the time of writing of his RFC the spec spec said META was
separated from STATUS by a tab (whereas now it is just whitespace), so
tacking something after META with another tab was unambiguous, assuming
nobody put tabs in their MIME types...

Another possibility ties into another request I got from somebody very
early on - it would be nice if there was some way to query a Gemini
server for the time a resource was last modified, so that Gemini
equivaents of tools like moku pona could avoid needlessly fetching
unchanged resources over and over again.  At that point I started
wondering about giving Gemini some equivalent of HTTP HEAD, although I
abandoned it pretty quickly when I realised that substantial TLS
overhead probably made making a whole second request to check if a
resource had changed not such a worthwhile idea.  But, we could possibly
bring this idea back, as the response to such a request could naturally
include the file size as well.  The real question is how to *make* such
a request, ideally in a way which doesn't open the door to a half dozen
other new "methods".

At this point I'm not necessarily convinced that either of these
problems warrant changes to the protocol.  It's not that I can't see how
it would be nice to work around them, but at some point one has to
accept that protocols which are simple and minimalist by design are
inevitably going to have some rough spots as a result of that design.
But if anybody has particularly elegant solutions, I'm all ears.

Regarding ways to enable something like a HEAD request without changing
the request format to include a method field - I'm not quite sure
whether using a fixed URL fragment, like #meta, on requests would be a
kosher way to do this.  Does metadata count as "some portion or subset
of the primary resource, some view on representations of the primary
resource, or some other resource defined or described by those
representations" (from RFC3986)?

-Solderpunk

---

Next in thread (2 of 11): 🗣️ Sean Conner (sean (a) conman.org)

View entire thread.