External SHA hashes instead? (was: Re: Content length, EOF -- ways to resolve whether we received everything)

[Nathan Galt]

> On Oct 30, 2020, at 4:50 AM, Björn Wärmedal <bjorn.warmedal at gmail.com> wrote:
> 
> There's been a lot of discussions about the lack of an end-of-message indicator in the protocol. Clearly it's something that a lot of client and server implementers are missing.
> 
> A proposal that arose (I think acdw may have been the first to suggest it; correct me if I'm wrong) was to include a "content-length: <nr of bytes>" in the <META> of a status 20 response. It's a simple thing to add, that doesn't extend the protocol into bloat.
> 
> "But, ew0k! The <META> is for MIME types! That's not a MIME type!"
> 
> Yes, this is true. Would that cause an issue? In that case calling it "x-gemi-content-length" should resolve it, as the "x-" prefix is for experimental types and any receiver that doesn't recognize it will ignore it. I'm aware that it still doesn't convey info on the *type* of content, and thereby doesn't belong among MIME type info, but it's a compromise I'm willing to make.
> 
> Are you?
> 
> Cheers,
> BW/ew0k


If you’re worried whether the occasional big(gish) file transferred correctly and don’t want to stand up an HTTP server, have you considered publishing SHA-256 or -512 hashes, like one does for Linux-distribution .iso files?