💾 Archived View for gemi.dev › gemini-mailing-list › 000591.gmi captured on 2024-08-19 at 01:18:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Is this a valid response? Just 2, followed by text/gemini content? 2 ... <eof> In other words: ? 2 ? 20 ? text/gemini ? text/gemini;charset=utf-8 Kosher?
Petite Abeille <petite.abeille at gmail.com> writes: > Is this a valid response? Just 2, followed by text/gemini content? > > 2 > ... > <eof> > > In other words: ? 2 ? 20 ? text/gemini ? text/gemini;charset=utf-8 > > Kosher? gemini://gemini.circumlunar.space/docs/specification.gmi > Gemini response headers look like this: > > <STATUS><SPACE><META><CR><LF> > > <STATUS> is a two-digit numeric status code, as described below in 3.2 and in > Appendix 1. So it isn't allowed by the spec and, personally, I don't see how allowing single-digit response could be a good idea.
> On Dec 30, 2020, at 11:58, Omar Polo <op at omarpolo.com> wrote: > > So it isn't allowed by the spec and, personally, I don't see how > allowing single-digit response could be a good idea. Right. So, no more 1 digit response code (i.e. generic success "2" use to be a thing), and no more default content-type (i.e. text/gemini). So a minimal valid response would be: 20 text/gemini ... <eof> Correct?
> On Dec 30, 2020, at 12:48, Petite Abeille <petite.abeille at gmail.com> wrote: > > So a minimal valid response would be: > > 20 text/gemini Actually: 20 text <eof> No need for a subtype. Would that be the minimal viable response?
Petite Abeille <petite.abeille at gmail.com> writes: >> On Dec 30, 2020, at 11:58, Omar Polo <op at omarpolo.com> wrote: >> >> So it isn't allowed by the spec and, personally, I don't see how >> allowing single-digit response could be a good idea. > > Right. So, no more 1 digit response code (i.e. generic success "2" use to be a thing), and no more default content-type (i.e. text/gemini). I recall reading a mail from solderpunk (or maybe was someone else) regarding the fact that initially the codes were one digit only. Now two are mandatory. > So a minimal valid response would be: > > 20 text/gemini > ... > <eof> > > Correct? Yup. (btw, that's how my server replies to every request for gemini files, since charset=utf-8 seems to be redundant.)
Petite Abeille <petite.abeille at gmail.com> writes: >> On Dec 30, 2020, at 12:48, Petite Abeille <petite.abeille at gmail.com> wrote: >> >> So a minimal valid response would be: >> >> 20 text/gemini > > Actually: > > 20 text > <eof> > > No need for a subtype. is it still valid? Mind you, I am pretty ignorant regarding various standards, but a quick look at RFC2045, section 5.1 "Syntax of the Content-Type Header Field" seems to mark the subtype as required. Also "grammar" in the wikipedia page[0] mark the subtype as required: >type "/" [tree "."] subtype ["+" suffix] *[";" parameter] I'm missing something? > Would that be the minimal viable response? To be fair, with the *current* specification 20\r\n <eof> is the minimal response allowed, since the spec still has the phrase: > 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. but that's gonna be removed in a while (or at least is the impression I got from the other thread). I'm curios though, why are you trying to define the "smallest possible response?" [0]: https://en.wikipedia.org/wiki/Media_type
> On Dec 30, 2020, at 13:13, Omar Polo <op at omarpolo.com> wrote: > > is it still valid? Ah, actually, you are right, the subtype is required now (thought old style MIME had it optional). So text/* as a minimum I guess. > > To be fair, with the *current* specification > > 20\r\n > <eof> > > is the minimal response allowed, since the spec still has the phrase: There you go. So my first example then, plus two digits code. > but that's gonna be removed in a while (or at least is the impression I > got from the other thread). Is that so? Lost track over time. > I'm curios though, why are you trying to define the "smallest possible > response?" Well, to flush out all such questions, and know what to expect at a very minimum :) Which, as of today is: 20\r\n <eof> I.e. an empty text/gemini;charset=utf-8 response.
This is low priority for [spec] but we should rephrase parts of the appendix before finalizing. Omar Polo <op at omarpolo.com> wrote: > > Petite Abeille <petite.abeille at gmail.com> writes: > > >> On Dec 30, 2020, at 11:58, Omar Polo <op at omarpolo.com> wrote: > >> > >> So it isn't allowed by the spec and, personally, I don't see how > >> allowing single-digit response could be a good idea. > > > > Right. So, no more 1 digit response code (i.e. generic success "2" use > to be a thing), and no more default content-type (i.e. text/gemini). > > I recall reading a mail from solderpunk (or maybe was someone else) > regarding the fact that initially the codes were one digit only. Now > two are mandatory. > It's like you wrote. While the appendix still refers to single-digit codes*, meaning the first digit of the two digit code, the server still needs to send at least a filler zero as the second digit in a minimal server. The client can still ignore the second digit if it wants to.
> On Jan 1, 2021, at 07:07, Katarina Eriksson <gmym at coopdot.com> wrote: > > *) This might need some improvement in the phrasing of the spec. Referring to a code with two digits, where one of them is a filler, as a "single-digit code" is confusing if you don't know the history of the protocol. > Right you are. Formalism, good editing, and brevity will help tremendously. The specification has to be precise, not meandering. "Brevity is the soul of wit." -- William Shakespeare "Brevity is the soul of lingerie." -- Dorothy Parker https://quoteinvestigator.com/2016/02/25/brevity/ ? ???
---