#516679 gophermap h links misinterpreted

#516679#5
Date:
2009-02-23 00:44:25 UTC
From:
To:
h links in the gophermap file works correctly at the top-level gophermap,
but not in a subdirectory.  When using a gophermap at the subdirectory as
follows:

ramune/nietzsche:ramune: cat -A gophermap
1Entries from 2009^I2009^Ipsychosnugglebunnies.net^I70$
hATOM feed^IURL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml^Ipsychosnugglebunnies.net^I80$

This is the link the browsers get:

gopher://psychosnugglebunnies.net:80/h/ramune/URL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml

Firefox with Overbite using view source:
<a href = "gopher://psychosnugglebunnies.net:80/h/ramune/URL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml">

And the gopher client from Debian with '=':
Type=h
Name=ATOM feed
Path=/ramune/URL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml
Host=psychosnugglebunnies.net
Port=80
<URL:gopher://psychosnugglebunnies.net:80/h/ramune/URL%3ahttp%3a//psychosnuggleb
unnies.net/%7eramune/phlog/tubers.xml>

Gophermap was removed from the system to prevent confusion for clients.
If the directory contents are needed for analysis, I'd be happy to provide
them.

System is Debian/etch on x86-64.

#516679#10
Date:
2009-08-18 08:44:40 UTC
From:
To:
I have investigated this. The problem is that pygopherd interprets the 'URL:'
path as a relative path as specified in [1]. The resulting path
('/ramone/URL:..') is not a valid URL path as in [2] because it does not start
with 'URL:' or '/URL'.  So it looks like pygopherd is doing the right thing.
But the bucktooth FAQ has another entry ([3]) that explicitly mentions the
usage of relative URL's in gophermaps.

For the submitter: A workaround is prepending a '/' to the path. This will
always work. And note that the usage of port 80 in your example is incorrect:
The host and port of a menu line should point to the local gopher server, not
the remote URL server, so that it can render a redirection document for old
clients.

For the maintainer: Attached patch fixes this bug by explicitly checking for
this case.

[1]: <gopher://gopher.floodgap.com/0/buck/dbrowse%3Ffaquse%201>
[2]: <gopher://quux.org/0/Archives/Mailing%20Lists/gopher/gopher.2002-02?/MBOX-MESSAGE/34>
[3]: <gopher://gopher.floodgap.com/0/buck/dbrowse?faquse%205>

Regards,

#516679#15
Date:
2019-12-24 06:22:26 UTC
From:
To:
Dear submitter,

as the package pygopherd has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/937449

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

#516679#28
Date:
2023-01-16 06:12:30 UTC
From:
To:
pygopherd 3.0.0~git20221126.02c65d60-3 has been reintroduced into
Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/michael-lazar/pygopherd/issues