💾 Archived View for rawtext.club › ~sloum › geminilist › 005421.gmi captured on 2023-11-14 at 10:06:44. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

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

<-- back to the mailing list

[Spec] <META> in the response header is too vague

Sean Conner sean at conman.org

Mon Feb 22 01:27:48 GMT 2021

- - - - - - - - - - - - - - - - - - - 

It was thus said that the Great Solene Rapenne once stated:

From the specification in "3.1 Response headers" it seems there are no
current limitation to what could be used in META:
<STATUS><SPACE><META><CR><LF>
<META> is a UTF-8 encoded string of maximum length 1024 bytes,
whose meaning is <STATUS> dependent.
There is currently only the content type in it and possibiliy the lang
metadata added for text/gemini types.
Maybe I missed something about it in the spec, but it's really vague,
- Is it ok to add many data in the response and up to the client to do
something with them?

I'm not sure if "okay" is the right answer, but the MIME type (per thespec) is defined in RFC-2045 (not RFC-2046 as stated---it's a typo) andthere, a consumer should be able to deal with parameters it doesn'tunderstand (read: ignore).

- Should clients be strict and error in case of unknown fields?

No. Too hard to maintain strictness when new MIME types and parametersare added.

- What is planned for? It has 1024 bytes and doesn't use much, it seems to
be ready for something else "just in case".

Nothing but parameters.

-spc