💾 Archived View for gemi.dev › gemini-mailing-list › 000736.gmi captured on 2024-03-21 at 18:01:47. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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? - Should clients be strict and error in case of unknown fields? - What is planned for? It has 1024 bytes and doesn't use much, it seems to be ready for something else "just in case".
On Sun, Feb 21, 2021 at 3:05 PM Solene Rapenne <solene at perso.pw> wrote: > 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? > - Should clients be strict and error in case of unknown fields? > - What is planned for? It has 1024 bytes and doesn't use much, it seems to > be ready for something else "just in case". > My implementations of server/client use the META field to communicate between the server and the user (through the client) - and in many cases, the value in META *is* limited and well defined by the current spec. See the 10 and 11 status codes - the prompt that the user should be shown is the value of the META field. The 3x status codes - the META is the location the server is redirecting the client to. Etc. (there are other places that META has specific meaning - even if the exact value is left up to the implementor , like on status 10 - as the spec says, the meaning of META is <STATUS> dependent) Does that help? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210221/7e46 ed58/attachment.htm>
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 the spec) is defined in RFC-2045 (not RFC-2046 as stated---it's a typo) and there, a consumer should be able to deal with parameters it doesn't understand (read: ignore). > - Should clients be strict and error in case of unknown fields? No. Too hard to maintain strictness when new MIME types and parameters are 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
---
Previous Thread: [SPEC] Backwards-compatible metadata in Gemini