Cache duration and response body size proposals

[Arav K.]

We just had massive discussions about both of these on the ML.  I'll
provide you with some of my thoughts and consensuses(?) from the
conversations in the ML:

> Caching
> Content-Size / Content-Length

Both of these proposals and the general idea around them focuses on
the transmission of large files.  Caching is geared towards reducing
request times, and content-size/length aims to provide progress bars and
size verification.  Content hashing, which you've not discussed, is also
toward content verification.

Gemini is focused on serving small textual files.  They clearly do not
need caching.  Clients that do wish to cache should only cache backward
and forward in history (i.e. pages that the user had visited in the
current session), and should provide a reload button at least for these
pages so that they can be refreshed when needed.  In addition, large
files are not expected to be requested repeatedly (at least, Gemini is
not the protocol to do it in), so they do not need to be cached.  Small
text files are also small enough that their size does not need to be
known (as they load quickly enough to remove the need for progress bars)
and they can easily be verified by hand just by reading them (the
underlying connection is already over TLS, so receiving bad data is hard
enough as it is).

Gemini is just not good at large transmissions, and this is intentional.
If you need to do large transmissions, use other protocols that already
support content-size (and perhaps content-hash), as they are geared
towards such transmissions and will support it better.

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/af871fb9/attachment.sig>