Proposal about content-size and hash

[A. E. Spencer-Reed]

Wait, what defines whitespace? I have a terrible idea...

On Mon, Nov 2, 2020 at 1:54 PM <prisonpotato at tilde.team> wrote:
>
> > ...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/gemini
> 22 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



-- 
🍵