Re: itype 3 as generic status Re: To evolve or not to evolve
It was thus said that the Great Mateusz Viste once stated:
>
> Cameron made a valid point about languages, though. I think that the
> description string should be left 100% dedicated to human texts to not
> pollute the user's visual space. Perhaps could we abuse the "port" field
> of the error item line to provide a 16-bit error code? This field is
> currently useless anyway for error lines.
>
> Such approach would prevent using the "3" line for redirecting the user
> somewhere else, but maybe it's for the best, because a "3" line is not
> supposed to be selectable in the first place, so a proper "1" or "0"
> line must be present anyway for non-smart clients so the user can click
> on it.
The only reason I did what I did was to inform users (in a backwards
compatible way) that the resource has moved (which happened to me, and it
took a while to find the new location).
> The convention could be "if first line of menu is a 3 error with code
> 301 in port field then client might want to follow the first selectable
> line of the menu".
It's not clear from RFC-1436 how clients are supposed to handle errors.
The word 'error' only apears twice, both times describing a type code of
'3'. There's no indication what should happen if a gopher menu has a type 3
error in it, nor what to do if a clients select a binary file and it returns
a type 3 error (is the error downloaded and saved as the file? My guess,
probably yes for most clients).
I've gone through the code for my gopher server [1] and there are four
error types I send a type 3 for:
Redirects (using my hack)
Gone (again, using my hack)
Bad Request (couldn't parse the selector)
Selector not found (generally, for any other error that may happen)
This is one area where gopher is seriously lacking.
-spc
[1] https://github.com/spc476/port70
Reply to: