💾 Archived View for rawtext.club › ~sloum › geminilist › 007524.gmi captured on 2023-11-14 at 08:32:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Michael Lazar lazar.michael22 at gmail.com
Wed Nov 3 19:59:20 GMT 2021
- - - - - - - - - - - - - - - - - - -
Greetings,
It sounds like what you are asking for is akin to the HTTPContent-Disposition response header [0]. I don't think it's a crazyidea... I mean gemini already has content-type, charset, and lang, andcontent-disposition snuggles right in there with those.
I will suggest that making this part of the response meta, instead ofan additional gemtext link type, feels like a more complete solution,for the same reason that mime-type is declared in the response.Someone might visit a gemini URL directly, or the response from theserver might be dynamically generated.
Gemini doesn't have response headers, and suggesting additionalresponse parameters will go nowhere on this list (although you couldadd them anyway and they probably won't break most clients).
20 image/png; content-disposition=attachment
However, I think you could get away with simply responding with acontent type of "application/octet-stream" for these files. No sanegemini client is going to attempt to display that inline, and onceit's saved to the filesystem then it's up to the filename extension toindicate what the mimetype is.
gemini://myserver.com/mysong.mp320 application/octet-stream
Best,Michael
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition