💾 Archived View for rawtext.club › ~sloum › geminilist › 000466.gmi captured on 2020-09-24 at 02:33:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Mon Mar 2 01:39:18 GMT 2020
- - - - - - - - - - - - - - - - - - - ```
It was thus said that the Great Ciprian Dorin Craciun once stated:
>
> * either it's not enough, given that we've already used 50% of the
> "generic class of conditions" (i.e. first digits 1 through 6); soon
> enough, as the protocol progresses and matures, we'll identify new
> classes of conditions, and we'll have to start to either introduce a
> "miscellaneous" category, or use values from other categories,
> breaking thus the clear hierarchy;
Before the mailing list, solderpunk and I went back and forth over thestatus codes. solderpunk was intent on using single digit codes, whereas Iwas pushing for three digit codes. As I wrote to him back in July of 2019:
> With a two digit scehem, you have at most 100 error codes (00 through 99),
> with very clearly delineated classes that makes it easy for a client to act
> upon just the first digit.
>
> With your one character scheme (and yes, I'm calling it "one character"
> and not "one hexidecimal") the grouping is less clear, and it can *still* be
> extended out to a total of 94 codes (if you use other characters). Also,
> what should happen when a client receives a code of 'a' through 'f'? Is it
> only upper case allowed? Or the lower case version as well? Because in
> hexidecimal, 0xF and 0xf are the same value.
>
> What are you really afraid of? Expansion? Gopher gives you two
> results---the content or nothing. A bit brutal, but simple. You can cut
> this down to just four cases:
>
> success
> transitory error
> permanent error
> need authorization
>
> but that's still a bit brutal. Just because you have 100, or 400, error
> codes doesn't mean they all will get used. I'm sure the top three codes
> seen in the wild for HTTP are:
>
> 200 Okay
> 304 Not modified
> 404 Not found
>
> with the following codes just enough to show up:
>
> 302 Move temp
> 301 Move perm
> 403 Not authorized
> 500 Internal error
>
> and the rest are rounding errors. I can't seem to find any evidence to back
> this up, but that's my gut feeling. I think a single character response
> code is just too llmiting and yet, ripe for more abuse than with a two-digit
> numeric range.
Also, the use of three digit status codes goes back a long time. In fact,it was first proposed in RFC-360, dated June 24, 1972! [1] And guess what? It was almost a one-to-one mapping of current HTTP status code. 2xx whereokay, 3xx were different, but I could see the mapping, 4xx were clienterrors and 5xx were server errors. There were also 1xx, but HTTP/1.1defined 1xx status as well.
And if anything, the fact that no new status classifications have come upin 48 years says that your fears of new categories might not be warranted.
> * some conditions don't fall particularly well into clear categories;
> for example `21 success with end of client certificate session` has to
> do with TLS transient certificates management (which is `6x`);
Fair enough, but solderpunk would have to fix that one.
> in
> fact this shouldn't even be a status code, but a "signal", because for
> example a redirect or other failure could as well require the end of
> client certificate session;
Again, fair enough. I'm sure some of this is speculative anyway, since Idon't think any servers have actually implemented this feature (I know Ihaven't).
> * another example of "unclear" status codes are `42 CGI error` and `43
> proxy error`, which are part of the `4x temporary failure` group, but
> might be in fact (especially in the case of 43, although granted we
> have 53) permanent errors; (even `51 not found` can be seen as a
> temporary error, because perhaps the resource will exist tomorrow;)
Yes, solderpunk changed from client errors/server errors totemporary/permanent errors. I didn't fight it that much since I can see thelogic in it.
> * and speaking of proxies, we have `43 temporary proxy error` and `53
> proxy request refused`, but we have no other proxy related statuses
> like for example `6y` that states `proxy requires authentication`,
> etc.;
I can see the argument for a "AUTHORIZATION FOR PROXY" error, but by thesame token, what type of certificate? (and even there, I think having threedifferent types of certificates is certainly a bit of confusion). This mayrequire some clarification from solderpunk in the mean time.
> So, if we really want to keep things simple why not change this into:
>
> * (we only use one digit to denote success or failure);
> * `0` (i.e. like in UNIX) means success, here is your document;
> * `1` (i.e. again like in UNIX) means "undefined failure", the client
> MUST display the meta field to the user as plain text; (please note
> that this "soft"-forbids the client and server to implement any clever
> "extensions";)
I still like numeric values as they are language agnostic. I mean, whatIf I get back:
Bhà teip ann an clár a chur i bhfeidhm
Would you even know what language to translate from?
Yes, most likely this would be English, but I am ornery enough to followthe letter of the law if not the spirit.
> * `2` not found / gone; (i.e. the server is working fine, but what
> you are searching for does not exist at the moment; perhaps it
> existed in the past, perhaps later it will exist;)
There is a distinction between "gone" and "not found". "Gone" means "itwas once here, but has since been removed, please stop referencing thisresource" (i.e. "remove it from your bookmarks file"), while "not found"means just that---it's not here.
I mentioned to solderpunk that I wish gopher had a "gone" message (alongwith redirect, which I'll get to below), since there is a good reason tomark something as "gone" and not just "not found".
> * `3` redirect; neither temporary nor permanent; (because in fact
> there isn't a clear definition and usage of temporary vs permanent;)
I think there is:
* permanent---this resource has permanently moved, and any future reference should use the new location (i.e. update your index or bookmark file!)
* temporary---this reference is still a valid reference, but the acutual content is, for whatever reason, located there.
A valid reason for a temorary redirect might be to redirect users to themost current resource available, say, a specification. A base link like:
gemini://gemini.example.com/foobar-spec
could in fact do a temporary redirect to
gemini://gemini.example.com/foobar-spec.1.3.2
One can always link directly to a specific version, but the current will*always* be found at a known location.
The actions are the same, but the semantics are different.
>
> I do fail to see why what appears to me to be a whole lot of work to
>
> implement what you suggest,
>
> Now getting back to my "symbolic" status codes proposal, it's no more
> work, because currently the code looks like:
>
> ````
> if (status[0] == '1') {
> ...
> } else if (status[0] == '2') {
> ...
> }
> ````
>
> Meanwhile my proposal would require one to:
> ````
> if (hasprefix (status, "success:")) {
> ...
> } else if (hasprefix (status, "redirect:")) {
> ...
> }
> ````
>
> Granted now one has to implement, or find already implemented the
> `hasprefix`, but all languages have it, and even in C one can
> implement it as `strncmp (status, expected, strlen (expected)) == 0`.
Nice, but you still need a function to check the second (and possibly)third fields. There's strtok() (a standard C function) but that can't beused in multithreaded applications ...
>
> , especially considering that most servers
>
> will invariably choose to implement their own custom handlers for
>
> status/error codes, much like one does in Apache so the server operator
>
> themselves gets to choose what content to deliver as a result of a 404.
>
> No this proliferation of "status codes" won't happen because the
> protocol won't allow for it. (Although even today with numeric status
> codes people can just invent their own, unless we clearly define
> conditions for all 100 codes, and even then people can disregard their
> definitions...)
That can be done now. I can program a web server to return a status of700. Now what clients will do in that case ... hmm ... okay, a quick testrevealed the following:
Firefox - treated a status code of 700 as a 200 and displayed the page
Safari - treated a status code of 700 as a 200 and displayed the page
Lynx - warned of the nonstandard status code, and then proceeded to treat 700 as 200 and displayed the page.
-spc
[1] There is also RFC-354, an earlier RFC but one dated two weeks after RFC-360, that also uses three digit status codes similar to RFC-360.