Specs and 0-length <META>

[Solderpunk]

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ò