Cache duration and response body size proposals

[Robert "khuxkm" Miles]

November 10, 2020 9:34 AM, "bie" <bie at 202x.moe> wrote:

> On Tue, Nov 10, 2020 at 02:17:13PM +0000, khuxkm at tilde.team wrote:
> 
>> It's *possible* to serve large files over Gemini. I can make a script that generates a large image
>> (or I can just have a large image to serve). Therefore, you should be able to use Gemini to serve
>> large files. The main draw I can see for a Content-Length header is being able to see if the whole
>> file comes across the wire. The ability to resume an interrupted download need not exist; just
>> retry the request if all of the content doesn't get across.
>> 
>> That being said, I am wary of making it even a SHOULD. If the file needs it (i.e; it's a big file
>> that probably could get interrupted mid-download), then go ahead, but those of us who don't care
>> about Content-Length or Cache duration shouldn't feel "pressured" to do it.
> 
> I'm far from a TLS expert, so I might be completely wrong here, but
> can't the client rely on the server's TLS close_notify signal to decide if
> the download was interrupted? As far as I can tell, the entire point of
> close_notify is to guard against data truncation...?
> 
> bie

I mean, yes, that's the point of close_notify, but what if the connection dies *after* the data is sent but *before* the close_notify can be sent? Then it turns into an unsolvable two-generals problem.

I'm not *advocating* for either proposal, I'm just sick and tired of people acting like "Gemini is meant for small text files" is a good excuse to ignore proposals that could help UX when downloading larger files.

Just my two cents,
Robert "khuxkm" Miles