This was discussed previously in the following thread: gemini://gemi.dev/gemini-mailing-list/messages/000012.gmi Which I'm now going to re-read to remind myself of what was said. From memory, I wasn't keen about adding extra fields to the META part of the response header, for my usual fear of opening the gates to people adding on weird non-standard extensions once it's established that more than exactly one thing is allowed there. Interestingly, I somehow forgot about this ubiquitous fear of mine with regards to the recent proliferation of text/gemini line types... Cheers, Solderpunk On Sat, Jan 18, 2020 at 06:05:35PM +0100, Julien Blanchard wrote: > Thanks to gemini://konpeito.media I noticed we might be missing the > content size information in some cases, mostly binary files. > With content that takes some time to be downloaded it would be nice to > be able to show the user the download progress. Most clients currently > leave the user in the dark regarding what's happening. Since I hope > that Gemini will be used for more medium than text as cat uses it, > this would be a nice addition to clients. > I would imagine this added meta only for non `text/whatever` content. > > There is also another need I felt being a client developer, it's > knowing what mime type an URL will return to be able to treat/display > it differently without necessarily getting the content.? Could we > imagine a standardized way to query an URL just for it's meta header > maybe? > > These are really client dev concerns and I feel this might be overkill > and going against the simplicity we want but I had to ask :)
---
Previous in thread (1 of 7): 🗣️ Julien Blanchard (julien (a) typed-hole.org)
Next in thread (3 of 7): 🗣️ Julien Blanchard (julien (a) typed-hole.org)