Closed Bug 96887 Opened 23 years ago Closed 19 years ago

gopher: No connection refused error

Categories

(Core :: Networking, defect, P5)

defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: greenrd, Unassigned)

References

()

Details

Attachments

(1 obsolete file)

If port 70 is blocked by a firewall and you haven't set a gopher proxy in prefs, mozilla should give a connection refused dialog box when you try to access a gopher URL, but it doesn't.
I'm sorry, this attachment went on the wrong bug. If you can delete the attachment and this comment, please do. I forgot that after submiting comments it skips you to the next bug in your list instead of taking you back to the bug you were on... Augustus
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: ui
Priority: -- → P5
Target Milestone: --- → mozilla1.0
Also happens if using SOCKS and SOCKS connection fails...
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
+ mozilla 1.0 - demanding a "connection failed error" for Mozilla 1.0 does not seem unreasonable to me...
Keywords: mozilla1.0
Adding dependencies for bug 28586 and bug 61685. I think that's right.
Depends on: errorpages, 61685
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla1.0.1 → Future
Keywords: mozilla1.0mozilla1.2
Attachment #47473 - Attachment is obsolete: true
Summary: No connection refused dialog box if gopher connection fails → gopher: No connection refused error
Actually, this is much more annoying than I thought, because it happened in real life when I was running my networking smoketests.
Severity: trivial → normal
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
Mozilla 1.3f Recent milestones display the URL and then an empty gopher page (between two horizontal bars). I think this started around 1.3a, I'll go back and check. Phoenix 0.5 seems to just leave the status as "Connecting to <gophersite>" This recently became more of a problem, because it looks the original gopher site (gopher.tc.umn.edu) is gone, after months of becoming more and more unreliable. I also found that gopher does not display DNS errors, I'll file a bug and put it in the meta bug.
Blocks: 194220
Flags: blocking1.4a?
+clean-report. -> defaults I've updated the URL so it will be a testcase on any system that is NOT running a local gopher server. Opps. My comments above were actually about bug 164283. You'd think I'd be able to tell the difference. (Then again, the lack of error messages for each made it less than obvious). In the past, that site was refusing connections, but now it is completely gone. Anyhow, the error does come back from necko, but is not displayed, you can tell because mozilla 1.3b had a regression that caused networking errors to jump out as "no data in document" on Win32 and Linux. Run 1.3b and click on the URL link, and you will see what I mean.
Flags: blocking1.4a? → blocking1.4a-
*** Bug 197343 has been marked as a duplicate of this bug. ***
QA Contact: benc → gopherqa
Works on current trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: