Specs and 0-length <META>

[Nicolò Balzarotti]

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ò