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/

Is this related to bug 17116?

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.

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

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

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.

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.

+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.

over to bbaetz@student.usyd.edu.au.

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

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).

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

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.

duping to the bug with a patch *** This bug has been marked as a duplicate of 202188 ***

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/

VERIFIED/dupe.

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.