184180 - gopher directory links not working

Status: VERIFIED DUPLICATE of bug 202188

(Core :: Networking, defect)

Description

[Sean MacLennan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021014 Phoenix/0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021014 Phoenix/0.3

There seems to be a disconnect between the code that builds the gopher directory
hrefs and the code that sends the links. Specifically, the directory href is a
complete URL while the code that sends to the gopher server expects a selector.

I believe the full url is correct, since the url may point to another server.

Reproducible: Always

Steps to Reproduce:
1.gopher://seanm.ca/
2.click on About
3.

Actual Results:  
The gopher server recieves a request for opher://seanm.ca/0/About.txt
Note the g is stripped off as the selector type!

Expected Results:  
It should have sent   0/About.txt

Note: I was testing this in the CVS 0.5 version of Phoenix. I am posting from
0.3 on a different machine.

I have tried different patches to fix this. Storing only the selector in the URL
from nsGopherDirListingConv::DigestBufferLines fixes it for local urls but
breaks others. Stripping the gopher://host in nsGopherChannel::Init fixes it for
all urls, but the directory listings end up with bad titles. For example:

gopher://fillmore/gopher://fillmore/1/nerd/

Comment 1

[benc]

Is this related to bug 17116?

Comment 2

[Prognathous]

This bug happens on Windows too (exact same behavior with Phoenix 0.4 and a 
complete failure to display Gopher sites with Mozilla 1.2.1).

Please change OS to All.
BTW, don't you think that it's a bit over-the-top to mark a Gopher-related bug 
as "Major"? after all it is 2002~3 (10 years past the glory days of this 
protocol...)

As a simple workaround, use a Proxy server. For example:
File>>Prefs>>Advanced>>Proxies>>Gopher Proxy: host005.answer.co.jp Port:80

Prog.

Comment 3

[benc]

*** This bug has been marked as a duplicate of 171116 ***

Comment 4

[Sean MacLennan]

I beg to differ. 171116 deals with problems in the html->text converter (and
originally, the lack thereof). This bug deals with a bad interaction between the
directory listing created and the rest of the gopher code. The fix for this bug
does not fix 17116 and versa visa.

If someone could point out where the "Index of" header is created, I am close to
having a patch that works around this bug but not 17116. 

P.S. I marked this major since it breaks basically all the gopher functionality,
except the top level gopher directory (which is handled as a special case).

/Sean

Comment 5

[Prognathous]

I don't think it's a dupe of Bug 171116, but it might be of Bug 149322 ("gopher:
Page doesn't load in Mozilla, but does in IE").

Prog.

Comment 6

[Neil Fraser]

I'm seeing this error in 1.3a on win98.

No, this isn't the same as Bug 149322.  That's a failure to load, this is a
failure to assemble a valid URL.  You can see the error just by hovering over a
gopher link, you don't even need to click it.

And yes, this is a major error, it causes 100% loss of gopher functionality
beyond the first page.

Comment 7

[benc]

+clean-report
good point. I had missed that while trying to find dupes.
I see the broken mouse-overs in Mozilla 1.3a/Win98 as well. 

Comment 8

[Doug Turner (:dougt)]

over to [e-mail].

Comment 9

[Bradley Baetz (:bbaetz)]

All my moz bugs are going to be FUTUREd for the forseeable future; if someone
has a patch, feel free to take.

Comment 10

[Sander]

The behaviour described in the first post seems to have been fixed (using
2003013108), however, now all links are apended to the current uri, giving
results such as gopher://seanm.ca/gopher%3A%2F%2Fseanm.ca%2F11%2Frfc (apprently
the 'fix' similar to the one described in comment 0 went in).

Comment 11

[gopherqa]

+1.4a If we can't fix this, gopher navigation is pretty much impossible.

Comment 12

[benc]

Does anyone know if there was a fix somewhere that took care of the original
bug, but created the new problem?

If not, I'm content to let the problem description remain the same, but let the
specifics drift.

Looking further at sander's comment, the problem is in the generated HTML, where
the HREF is: 'gopher%3A%2F%2Fseanm.ca%2F00%2FAbout.txt"

We need to generate an unescaped string, because that forces the URL code to see
"gopher:" and treat the URL as absolute.

Index/html + URL parsing changes might have caused this, I noticed that file and
 ftpdon't have this problem because they only create entries that are relative.
Gopher links can point outside the server authority.

Comment 13

[Bradley Baetz (:bbaetz)]

duping to the bug with a patch

*** This bug has been marked as a duplicate of 202188 ***

Comment 14

[Andrew Schultz]

the behavior in this bug switched from the originally reported behavior (nothing
happens when "About" is clicked) to the behavior in bug 202188 (bogus gopher URL
visited when clicking "About") occured during the window when bug 177964 was
checked in (2002120422 - 2002120605).

with darin's patch from bug 202188, clicking "About" works fine at
gopher://seanm.ca/

Comment 15

[benc]

VERIFIED/dupe.

Comment 16

[Jan Ruzicka]

Is this a correct place to make the fix?

http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsGopherDirListingConv.cpp


this looks like it is dealing with the compisition of the page and the links.