💾 Archived View for rawtext.club › ~sloum › geminilist › 002968.gmi captured on 2020-10-31 at 14:54:01. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Björn Wärmedal bjorn.warmedal at gmail.com
Fri Oct 30 11:50:24 GMT 2020
- - - - - - - - - - - - - - - - - - -
There's been a lot of discussions about the lack of an end-of-messageindicator in the protocol. Clearly it's something that a lot of client andserver 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, thatdoesn'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 forexperimental types and any receiver that doesn't recognize it will ignoreit. 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'mwilling to make.
Are you?
Cheers,BW/ew0k-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201030/a9a59223/attachment.htm>