Specs and 0-length <META>

[Björn Wärmedal]

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ò
>