Specs and 0-length <META>

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?