💾 Archived View for rawtext.club › ~sloum › geminilist › 003010.gmi captured on 2020-11-07 at 03:17:45. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
prisonpotato at tilde.team prisonpotato at tilde.team
Mon Nov 2 18:54:32 GMT 2020
- - - - - - - - - - - - - - - - - - -
...I suspect I'll regret sharing this, but intellectual honesty compels
me. It's just occurred to me that this problem can actually be avoided by
having the <META> value for status code 20 be the content size in bytes,
followed by arbitrary whitespace, followed by the MIME type. With this
approach, the designated separator between the size and the MIME type
is whitespace, but because MIME types may themselves contain whitespace
(to e.g. separate type/subtype from parameter values), it would be
extremely problematic to attempt to add any optional extensions on after
the MIME type using that same designated separator. Having the
separator possibly occur inside the final element of the list makes the
list self-terminating, which completely addresses my greatest fear with
having a list at all, as opposed to just a single bit of information.
This seems like a neat solution to this problem to me, but I'm not sure if it would work at this stage of gemini's life cycle. There are also of course the issues with dynamically sized responses as generated by CGI scripts and stuff like that, so maybe we could introduce a new response code, like 22: Response with size.
20 text/gemini22 100 text/gemini
This solves both problems by making content length optional again, but exposes a risk that this type of extension could be used to add more fields