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 of info in the spec - I don't know what solderpunk is going on about. Clients (that conform to the MIME parsing guidelines) will ignore it if they don't recognize it. It's not affecting anything else in the spec. I understand to some extent solderpunk's fear of MIME type parameters becoming the new HTTP header fields (or whatever they're called), but this has always been around as an avenue of extension. We can't even specify that unrecognized MIME type parameters be considered errors, because the MIME spec itself leaves open the possibility of adding more parameters later. I argue that if this avenue of extension is open, and it 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 stuff before sending a success response (in case the CGI fails; see the CGI-specific error code in the spec). Immediately after execution, it would have the full response to send, so it can still provide the content size. Even then, it would still be optional to provide, as no servers currently provide it. > I also proposed something along these lines in August of 2019: > > gemini://gemi.dev/gemini-mailing-list/messages/000016.gmi > > Read the thread to see how that turned out. >From what it seems, you suggested the same thing I have a year back, and solderpunk said 'ah' and then it was forgotten. Here's what solderpunk's last response to the idea from that thread had been: > 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 to report this information. I think we should 'officially' resume discussion of this, and we can start by figuring out issues with this MIME type parameter proposal. In addition, someone reminded me how short content hashes are in comparison to the available space in the META line. Even SHA-512 takes up only 140 characters out of the 1024 available on META, so we can actually encode content-hash as well in the MIME type. I understand this is even more controversional than content-length, but I'm leaving it out there for discussion. ~aravk | ~nothien
---
Previous in thread (9 of 48): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (11 of 48): 🗣️ Nathan Galt (mailinglists (a) ngalt.com)