💾 Archived View for rawtext.club › ~sloum › geminilist › 002981.gmi captured on 2020-11-07 at 03:16:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-10-31)
-=-=-=-=-=-=-
Nathan Galt mailinglists at ngalt.com
Fri Oct 30 22:34:00 GMT 2020
- - - - - - - - - - - - - - - - - - -
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?