💾 Archived View for rawtext.club › ~sloum › geminilist › 002982.gmi captured on 2020-10-31 at 14:54:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Arav K. nothien at uber.space
Fri Oct 30 22:27:10 GMT 2020
- - - - - - - - - - - - - - - - - - -
On Fri Oct 30, 2020 at 12:06 PM UTC, Sean Conner wrote:
Ah yes ... this is something I proposed back in August of 2019:
gemini://gemini.conman.org/gRFC/0003
Solderpunk has always rejected it when it comes up, mumbling
"simplicity" and "not HTTP again" under his breath.
It would be a useful optional header that simply requires a few lines ofinfo in the spec - I don't know what solderpunk is going on about.Clients (that conform to the MIME parsing guidelines) will ignore it ifthey don't recognize it. It's not affecting anything else in the spec.
I understand to some extent solderpunk's fear of MIME type parametersbecoming the new HTTP header fields (or whatever they're called), butthis has always been around as an avenue of extension. We can't evenspecify that unrecognized MIME type parameters be considered errors,because the MIME spec itself leaves open the possibility of adding moreparameters later. I argue that if this avenue of extension is open, andit cannot be closed, then may as well make (optional) use of it.
Another issue with this is that the server might not know how big a
given response is---think dynamic output (via CGI/SCGI or similar). It
would have to be optional in any case.
For things like CGI, the server is expected to execute the CGI stuffbefore sending a success response (in case the CGI fails; see theCGI-specific error code in the spec). Immediately after execution, itwould have the full response to send, so it can still provide thecontent size. Even then, it would still be optional to provide, as noservers currently provide it.
I also proposed something along these lines in August of 2019:
https://lists.orbitalfox.eu/archives/gemini/2019/000016.html
Read the thread to see how that turned out.
From what it seems, you suggested the same thing I have a year back, andsolderpunk said 'ah' and then it was forgotten.
Here's what solderpunk's last response to the idea from that thread hadbeen:
Yeah, I think we can leave this for now. It was a hypothetical
concern that somebody had. Not necessarily a bad one, but until it's
observed actually creating significant trouble for actual users on
actual clients I think we can just table this issue. If it does come
up as a practical concern, we can resume discussion of some of the
ideas here.
The problem has come up again, and more clients are looking for ways toreport this information. I think we should 'officially' resumediscussion of this, and we can start by figuring out issues with thisMIME type parameter proposal.
In addition, someone reminded me how short content hashes are incomparison to the available space in the META line. Even SHA-512 takesup only 140 characters out of the 1024 available on META, so we canactually encode content-hash as well in the MIME type. I understandthis is even more controversional than content-length, but I'm leavingit out there for discussion.
~aravk | ~nothien