Re: Strange interaction between UM Gopher and Gophernicus
On Fri, Nov 22 2019, David Griffith wrote:
>On Fri, 22 Nov 2019, Kim Holviala wrote:
>> Original author of Gophernicus here. You are all arguing about the
>> wrong thing here: the "problem" is that gopher the protocol has no
>> concept of filename so clients just have to guess one when saving
I completely agree. As I said in my earlier message, UMN gopher is
generating a default *proposed* filename based on the description. An
argument could be made that it should be based on the selector instead,
but personally I don't feel very strongly one way or other on this
issue.
>> Yes, Gophernicus interprets the gopher RFC "slightly" broadly and
>> uses the name field to give additional information to human users,
>> downside being that computer users might get confused. But it's not
>> against the RFC, just a different interpretation of it.
Agreed on this as well. There is nothing invalid about what you are
doing, nor about how UMN gopher interprets it.
> Where should we go from here? I've been trying to find an example of
Well one possible answer is to ignore it ;-) UMN gopher is just
proposing a default filename; it is up to you to decide what to name it
in the end.
> printf("%c%s%s %s %s\t%s%s\t%s\t%i" CRLF, type,
>
> If I change that line to this:
>
> printf("%c%s\t%s %s %s\t%s%s\t%s\t%i" CRLF, type,
> ^^
>
> This results in UM Gopher omitting the date and size. Floodgap's
> proxy won't render anything. Clearly then, UM Gopher is the one with
That's because you're violating the spec with this. It's supposed to
look like
TYPECHAR + DESCRIP + TAB + SELECTOR + TAB + HOST + TAB + PORT + EOL
(gopher+ adds a little something here)
What you did will cause -- at BEST -- the download to fail because
you're adding junk to the selector.
It does not follow that UMN gopher is the one with the problem. It
doesn't even follow that there's any problem with any software at all
(except your modified version)
> the problem -- other clients don't act like this. So now I have three
> questions:
>
> 1. What are the other clients doing to determine the end of the
> filename?
Web-adjacent ones (eg lynx) are no doubt constructing a gopher:// URL
and using the bits after the last slash.
>
> 2. Did any other servers provide date and filesize?
I don't recall ever seeing this. However, if this issue is seriously
bothersome to you, you could always instead provide the date and size
above or below the file itself as an i line.
>
> 3. Where can I find source code to historical gopher servers that
> were in service in the early 1990s?
I got you!
gopher://gopher.quux.org:70/1/Archives/mirrors/boombox.micro.umn.edu/pub/gopher
Way more than you wanted, I'm sure ;-)
pygopherd aims to be the evolution of UMN gopherd, the "canonical"
original gopherd which you can find under the "Unix" directory at the
place above. Note that UMN gopher and gopherd used to be distributed
together.
UMN gopherd, and also pygopherd, will, in the absence of some overriding
description in .names or some such, strip off the extension of a
filename for display purposes if the extension corresponds to a known
MIME type on the system. You can see that in action at
gopher://gopher.quux.org:70/1/Archives/mirrors/boombox.micro.umn.edu/pub/gopher/docs
You will, no doubt, observe that if you go to that location and attempt
to download GopherGuide_Jan12-94.ps that UMN gopher will suggest a
filename without the .ps. However, you can clearly see by pressing "="
on that line that the selector includes the .ps. So this situation has
been with us for a VERY long time. I cannot speak to the initial design
decision for the default in the UMN gopher client, other than it would
have been a deliberate choice and the tradeoffs would have been
well-known at the time.
Also remember that gopher+ has this notion of multiple views of a single
file. (For instance, PDF/Postscript) It has been a very long time since
I worked with this code, so the details escape me, but the choice that
UMN gopher makes may have to do with that. Remember that UMN gopher is
gopher+ client.
- John
Reply to: