Hello! MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed length for the <META> field. MasterQ32: To my understanding, <META> should be non-empty in any case, but it may not contain useful information. ew0k: My interpretation after re-reading the specification is that 1) A browser should be able to handle a zero-length meta field, because the specification does not un-ambigously state a minimum length - and 2) you should post a request for clarification on the mailing list, so that the specification is updated to be clear on the topic me: In section 3.1 there's a maximum length, but not a minimum, and under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be an empty string. Can the specs be changed so that it is stated exactly if/when an empty <meta> is allowed? Thanks! Nicol?
Hi, Good questions! The spec says (at the end of Section 3.3) that: > If <META> is an empty string, the MIME type MUST default to > "text/gemini; charset=utf-8". The text/gemini media type is defined in > section 5. which implies quite clearly that an empty <META> is possible, at least in the case of a status code of 20. It's pretty vague, though, about exactly what this means, and when else it might be allowed. Since a response header is defined as: > <STATUS><SPACE><META><CR><LF> an empty <META> strictly means "20 \r\n", with "20\r\n" being totally invalid. This probably was not what I had in mind at the time. It seems to me that an empty <META> with a status code of 3x must necessarily be invalid as it makes no sense to redirect to nowhere. An empty <META> with a status code of 1x could in principle be handled by using a client-specific default input prompt, but I think it would be quite poor design to actually return such a response. Users should always know what it is they're being asked to input, even if they visit the URL that leads to the prompt directly, without the context of some other URL which linked to it. Simplicity would dictate that either <META> may always be empty or must never be empty. There are two good reasons above not to allow <META> to be empty in some cases, so maximum simplicity argues for it never be allowed. We *could* just remove the final paragraph of Section 3.3 which specifies a default media type for successful responses. Has anybody written a server which actually makes use of this default? Does anybody see a particularly compelling reason to keep it in there? It saves only 11 bytes which is trivial compared to TLS overhead and TCP overhead. Cheers, Solderpunk On Mon Nov 2, 2020 at 2:44 PM CET, Nicol? Balzarotti wrote: > Hello! > > MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed > length for the <META> field. > > MasterQ32: To my understanding, <META> should be non-empty in any case, > but it may not contain useful information. > > ew0k: My interpretation after re-reading the specification is that 1) A > browser should be able to handle a zero-length meta field, because the > specification does not un-ambigously state a minimum length - and 2) you > should post a request for clarification on the mailing list, so that the > specification is updated to be clear on the topic > > me: In section 3.1 there's a maximum length, but not a minimum, and > under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be > an empty string. > > Can the specs be changed so that it is stated exactly if/when an empty > <meta> is allowed? > > > Thanks! > Nicol?
Clarity, simplicity, consistency :) As you say, there are cases where an empty META makes no sense at all (redirection). For me that's enough of a reason to say that META must never be empty, for the three above mentioned reasons :) Your argument is sound. Cheers, ew0k On Wed, 4 Nov 2020 at 21:41, Solderpunk <solderpunk at posteo.net> wrote: > > Hi, > > Good questions! > > The spec says (at the end of Section 3.3) that: > > > If <META> is an empty string, the MIME type MUST default to > > "text/gemini; charset=utf-8". The text/gemini media type is defined in > > section 5. > > which implies quite clearly that an empty <META> is possible, at least > in the case of a status code of 20. It's pretty vague, though, about > exactly what this means, and when else it might be allowed. > > Since a response header is defined as: > > > <STATUS><SPACE><META><CR><LF> > > an empty <META> strictly means "20 \r\n", with "20\r\n" being totally > invalid. This probably was not what I had in mind at the time. > > It seems to me that an empty <META> with a status code of 3x must > necessarily be invalid as it makes no sense to redirect to nowhere. > > An empty <META> with a status code of 1x could in principle be handled > by using a client-specific default input prompt, but I think it would be > quite poor design to actually return such a response. Users should > always know what it is they're being asked to input, even if they visit > the URL that leads to the prompt directly, without the context of some > other URL which linked to it. > > Simplicity would dictate that either <META> may always be empty or must > never be empty. There are two good reasons above not to allow <META> to > be empty in some cases, so maximum simplicity argues for it never be > allowed. We *could* just remove the final paragraph of Section 3.3 > which specifies a default media type for successful responses. Has > anybody written a server which actually makes use of this default? Does > anybody see a particularly compelling reason to keep it in there? It > saves only 11 bytes which is trivial compared to TLS overhead and TCP > overhead. > > Cheers, > Solderpunk > > On Mon Nov 2, 2020 at 2:44 PM CET, Nicol? Balzarotti wrote: > > Hello! > > > > MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed > > length for the <META> field. > > > > MasterQ32: To my understanding, <META> should be non-empty in any case, > > but it may not contain useful information. > > > > ew0k: My interpretation after re-reading the specification is that 1) A > > browser should be able to handle a zero-length meta field, because the > > specification does not un-ambigously state a minimum length - and 2) you > > should post a request for clarification on the mailing list, so that the > > specification is updated to be clear on the topic > > > > me: In section 3.1 there's a maximum length, but not a minimum, and > > under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be > > an empty string. > > > > Can the specs be changed so that it is stated exactly if/when an empty > > <meta> is allowed? > > > > > > Thanks! > > Nicol? >
Hi Solderpunk, thanks for the reply. > It seems to me that an empty <META> with a status code of 3x must > necessarily be invalid as it makes no sense to redirect to nowhere. > I agree on it either be optional or mandatory. And (unless implying some default-value like "/", "./" or something) you are right on "3X \r\n" being meaningless. In the wild we saw 5X status without meta (example [1]). I myself when implementing a server after reading the specs decided that "51 \r\n" was fine (because adding "Resource not found" after 51 seemed to me like a repetition), but on the other side "20 text/gemini" was just better than "20 ". Indeed, removing the paragraph of Section 3.3 would help, but I'd also replace _may_ (i.e. The contents of <META> _may_ provide additional information on the failure) with _should_. Thanks! Nicol? [1] https://github.com/MasterQ32/kristall/issues/43 "Solderpunk" <solderpunk at posteo.net> writes: > Hi, > > Good questions! > > The spec says (at the end of Section 3.3) that: > >> If <META> is an empty string, the MIME type MUST default to >> "text/gemini; charset=utf-8". The text/gemini media type is defined in >> section 5. > > which implies quite clearly that an empty <META> is possible, at least > in the case of a status code of 20. It's pretty vague, though, about > exactly what this means, and when else it might be allowed. > > Since a response header is defined as: > >> <STATUS><SPACE><META><CR><LF> > > an empty <META> strictly means "20 \r\n", with "20\r\n" being totally > invalid. This probably was not what I had in mind at the time. > > It seems to me that an empty <META> with a status code of 3x must > necessarily be invalid as it makes no sense to redirect to nowhere. > > An empty <META> with a status code of 1x could in principle be handled > by using a client-specific default input prompt, but I think it would be > quite poor design to actually return such a response. Users should > always know what it is they're being asked to input, even if they visit > the URL that leads to the prompt directly, without the context of some > other URL which linked to it. > > Simplicity would dictate that either <META> may always be empty or must > never be empty. There are two good reasons above not to allow <META> to > be empty in some cases, so maximum simplicity argues for it never be > allowed. We *could* just remove the final paragraph of Section 3.3 > which specifies a default media type for successful responses. Has > anybody written a server which actually makes use of this default? Does > anybody see a particularly compelling reason to keep it in there? It > saves only 11 bytes which is trivial compared to TLS overhead and TCP > overhead. > > Cheers, > Solderpunk > > On Mon Nov 2, 2020 at 2:44 PM CET, Nicol? Balzarotti wrote: >> Hello! >> >> MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed >> length for the <META> field. >> >> MasterQ32: To my understanding, <META> should be non-empty in any case, >> but it may not contain useful information. >> >> ew0k: My interpretation after re-reading the specification is that 1) A >> browser should be able to handle a zero-length meta field, because the >> specification does not un-ambigously state a minimum length - and 2) you >> should post a request for clarification on the mailing list, so that the >> specification is updated to be clear on the topic >> >> me: In section 3.1 there's a maximum length, but not a minimum, and >> under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be >> an empty string. >> >> Can the specs be changed so that it is stated exactly if/when an empty >> <meta> is allowed? >> >> >> Thanks! >> Nicol?
---