💾 Archived View for rawtext.club › ~sloum › geminilist › 007526.gmi captured on 2024-02-05 at 10:38:39. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Rethinking the link line

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