Closed Bug 202188 Opened 21 years ago Closed 21 years ago

Gopher support completely defunct

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: roland.mainz, Assigned: darin.moz)

References

Details

(Keywords: qawanted, regression)

Attachments

(1 file, 1 obsolete file)

v1.1 patch - same thing, slightly cleaned up
4.89 KB, patch
dougt
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
2003-04-09-08-trunk on Solaris/SPARC:

Gopher support seems to be broken

Steps to reproduce:
1. Go to gopher://gopher.quux.org/
2. Click on the link "People"

Result:
"Broken image" icon

Expected result:
Browser should surf to gopher://gopher.quux.org/1/People
ok, i'll look into this for 1.4 beta since you asked so nicely.
Severity: blocker → critical
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
It seems the URL is just concatenated to the URL of the previous document, e.g. 
surfing from gopher://gopher.quux.org/ to gopher://gopher.quux.org/1/People
results in gopher://gopher.quux.org/gopher%3A%2F%2Fgopher.quux.org%2F1%2FPeople
instead of gopher://gopher.quux.org/1/People

It seems that this should be easy to fix... darin ?
Severity: critical → blocker
Priority: P3 → --
Target Milestone: mozilla1.4beta → ---
sorry, mid-air collision.
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
Another nasty issue:
Protocol "guessing "is totally wrong.
Typing "gopher.quux.org" browses to http://gopher.quux.org instead of
gopher://gopher.quux.org ... ;-((
Should I file a seperate bug for that ?
> Should I file a seperate bug for that ?

Yes.

Your compreg.dat includes the line:

@mozilla.org/network/protocol;1?name=gopher,{44588c1f-2ce8-4ad8-9b16-dfb9d9d513a7}

right?
Boris Zbarsky wrote:
> > Should I file a seperate bug for that ?
>
> Yes.

This issue is now known as bug 202196 ('Mozilla guesses wrong protocol for host
names containing "gopher"') ... :)

> Your compreg.dat includes the line:
> 
>
@mozilla.org/network/protocol;1?name=gopher,{44588c1f-2ce8-4ad8-9b16-dfb9d9d513a7}
> right?

Yes, this is a clean build...

... why ?
Just making sure this is not a "necko2.dll not built" issue or something...

But just to check, do data: urls work?
Blocks: 194220
this is a regression from the checkin for bug 177964
Keywords: regression
OS: Solaris → All
Hardware: Sun → All
This is a dupe of bug 184180, if you ignore the drift from one version of link
bustage to another.

Maybe we should keep this bug open because it has the best info.
Blocks: 184180
actually, i think this is a regression from the checkin for bug 193477. 
nsIndexedToHTML needs to check whether the location is absolute or relative. 
the current escaping assumes always relative, which is not the case here.
1.3a (which predates bug 193477) exhibits this problem.  I backed out bug 177964
and gopher worked again.
ah, ok... got it.  thanks!
ok, the problem is that gopher:// unlike ftp:// and file:// can produce
directory listings with absolute URLs instead of just relative URLs. 
nsIndexedToHTML assumes that it will only get relative URLs from its input, so
it escapes colons to ensure that the HREF will not be treated as an absolute
URL.  gopher seems to be capable of producing gopher://, telnet://, and
tn3270:// links.  nsIndexedToHTML could be hacked with special cases for these
schemes, but that would really suck.  i'm trying to think of a better way. 
suggestions welcome.
hmm.. actually, it looks like gopher:// directory listings never contain
relative URLs.  i could just check the URL scheme in
nsIndexedToHTML::OnStartRequest (like we already do for ftp:// and file://) and
set a flag to treat all locations as absolute.  that might be cleaner.
Attached patch v1 patch (obsolete) — — Splinter Review 
ok, this patch implements what i suggested.  it seems to work.	i tested it
against a FTP server with a document named "foo:bar.txt" and it continues to
work.  i also tested the gopher site, and it works.
wrong patch.. meant to upload this one instead.
Attachment #120718 - Attachment is obsolete: true
Attachment #120719 - Flags: review?(dougt)
Flags: blocking1.4b?
Yeah, known bug which I haven't had time to fix yet. benc knows about it. I'll
dupe that one to this, since this has a patch.
*** Bug 184180 has been marked as a duplicate of this bug. ***
Severity: blocker → critical
Comment on attachment 120719 [details] [diff] [review]
v1.1 patch - same thing, slightly cleaned up

cause gopher is *so* important :-)
Attachment #120719 - Flags: review?(dougt) → review+
Gopher support *is* important. At least for me (I have a quota of 75MB for
Gopher at freeshell.org...)

Thanks for the fix,

Prog.
i am sure it is important to you and a handful of other people.  no disrespect
intented :-)
Attachment #120719 - Flags: superreview?(bzbarsky)
Attachment #120719 - Flags: superreview?(bzbarsky) → superreview+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Flags: blocking1.4b?
If someone wants to verify this, qa assign it to yourself, and put the build
number you used that works. Then change status to VERIFIED.
Keywords: qawanted
QA Contact: benc → gopherqa
Verifying...
Status: RESOLVED → VERIFIED
QA Contact: gopherqa → Roland.Mainz
*** Bug 177060 has been marked as a duplicate of this bug. ***
*** Bug 206922 has been marked as a duplicate of this bug. ***
*** Bug 190132 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: