💾 Archived View for rawtext.club › ~sloum › geminilist › 007526.gmi captured on 2023-09-08 at 16:33:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
The Gnuserland gnuserland at mailbox.org
Wed Nov 3 21:06:31 GMT 2021
- - - - - - - - - - - - - - - - - - -
Hi Michael,
this address the issue from a very technical perspective!
I wrote from a simple author/reader perspective I don't have enough knowledge or skill to get deep to this level, but sounds right what you wrote and more feasible.
Thanks,
TGL
On 11/3/21 15:59, Michael Lazar wrote:
Greetings,
It sounds like what you are asking for is akin to the HTTP
Content-Disposition response header [0]. I don't think it's a crazy
idea... I mean gemini already has content-type, charset, and lang, and
content-disposition snuggles right in there with those.
I will suggest that making this part of the response meta, instead of
an 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 the
server might be dynamically generated.
Gemini doesn't have response headers, and suggesting additional
response parameters will go nowhere on this list (although you could
add 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 a
content type of "application/octet-stream" for these files. No sane
gemini client is going to attempt to display that inline, and once
it's saved to the filesystem then it's up to the filename extension to
indicate what the mimetype is.
gemini://myserver.com/mysong.mp3
20 application/octet-stream
Best,
Michael
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition