Proposal about content-size and hash

<prisonpotato at tilde.team> wrote:

> 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
>

Remember, simple clients might only read the first "2" and treat it like a
"20".

If this was a year ago, maybe we could have gone with
"20<sp><size><sp><meta>" but what would be a valid size? Byte count only?
Approximate sizes like "20k" and "42M"? Ignoring trailing characters like
"5744267;<other_headers>"?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201102/bf79
534d/attachment-0001.htm>

---

Previous in thread (29 of 48): 🗣️ A. E. Spencer-Reed (easrng (a) gmail.com)

Next in thread (31 of 48): 🗣️ Philip Linde (linde.philip (a) gmail.com)

View entire thread.