💾 Archived View for rawtext.club › ~sloum › geminilist › 003064.gmi captured on 2020-11-07 at 03:19:58. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Nicolò Balzarotti anothersms at gmail.com
Thu Nov 5 08:25:54 GMT 2020
- - - - - - - - - - - - - - - - - - -
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 implyingsome 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 seemedto me like a repetition), but on the other side "20 text/gemini" wasjust better than "20 ".
Indeed, removing the paragraph of Section 3.3 would help, but I'd alsoreplace _may_ (i.e. The contents of <META> _may_ provide additionalinformation 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ò