Re: Strange interaction between UM Gopher and Gophernicus

[David Griffith <dave@661.org>]

My reply is at the bottom.  Please put your reply there too.
On Wed, 20 Nov 2019, John Goerzen wrote:
> Hi David,
>
> Thanks for the message (and also the one you sent to me privately).
> I've enabled the issues tracker for UMN gopher.
>
> In looking into this, when downloading a file locally, UMN gopher
> suggests as the name -- you can always edit it -- the name, NOT the
> selector path.  In this case, Gophernicus is sending a very long name,
> including spaces and the date, in the Gopher directory.  UMN gopher is
> simply taking it as the download suggestion.
>
> In the wild, I guess I rarely see things like tar.gz files have a
> different gopher name from the selector path.
>
> Is this a bug in UMN gopher?  To be honest, I'm not really sure.  It is
> certainly a Web convention to name downloaded files based on URL rather
> than hyperlink, but I can really see pros and cons either way in the
> Gopher context.  I'm presently working on porting Pygopherd to Python 3,
> so probably won't be working to develop a patch to UMN gopher on this
> myself right now - though if others want to submit one, given my lack of
> strong feelings one way or other, I'd be open to applying such.
>
> Hope that helps,
>
> John
>
> On Wed, Nov 20 2019, David Griffith wrote:
>
> > I noticed this odd interaction between the UM Gopher client and the
> > Gophernicus server that I initially thought was a bug in Gophernicus.
> > I reported it at https://github.com/gophernicus/gophernicus/issues/48
> > whereupon it seems to have been traced to a problem in UM Gopher.  To
> > make things worse, it manifests only with this client/server
> > combination.
> >
> > The basic problem is that with some file downloads, UM Gopher appends
> > a bunch of dashes and the file's datestamp appended to the end of the
> > filename.  Contrary to what Fosslinux states, the bug isn't
> > necessarily triggered by a long path.  After playing with debugging
> > fprintf()s, I found that at gopher.661.org, in the "Computer
> > Underground Digest" directory, all of the textfiles there will show
> > this problem.  The path there is simply cud/ with the text files
> > conforming to 8.3 filename length limits.
> >
> > I'd have filed an issue at https://github.com/jgoerzen/gopher, but the
> > issues button is disabled.

I think I found a smoking gun.  When Gophernicus serves up a directory 
containing a gophermap file, the selector is separated from the rest of 
the line by tab characters.  This is not so when the directory does not 
have a gophermap.  Also, if the if the -nd option is used with 
gophernicus, a tab is used as a separator.

If I'm reading the gopher rfc correctly, using spaces instead of tabs is 
illegal.  UM Gopher then keeps reading the string until the next tab is 
found, which just so happens to be right after the file size which is 
right where the garbled string stops.


--
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?