Closed
Bug 117875
Opened 23 years ago
Closed 9 years ago
close FTP control connections when no docshell actively displaying it
Categories
(Core Graveyard :: Networking: FTP, enhancement)
Core Graveyard
Networking: FTP
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: jmd, Unassigned)
References
Details
I connected to ftp://ftp.xpilot.org/ in Mozilla, saw I wanted a file, so I started a real FTP client. (Mozilla's downloading doesn't work, seperate issues). ---- Connecting to ftp.xpilot.org (132.235.197.27) port 21 <--- 220 XPilot FTP Server ready. ---> USER anonymous <--- 530 Only one connection per machine allowed. Saw Mozilla still had a connection open (acceptable, since the page was still showing, to hold the connection to avoid ftp login overhead if the user issues further commands. So I went to another page. Checked netstat output, saw the connection was still open. Went to another page, waited a minute or two, FTP connection was still in state ESTABLISHED. Had to close Mozilla so I could log in with another client.
Reporter | ||
Comment 2•23 years ago
|
||
Ah, thought there was a similar issue before... marked FIXED though, query didn't find it. This is 2001123108 Linux, 30 days after the check-in there. The user-visible effects of bug 43567 aren't really discussed, only internal handle/mem leaks, so I don't know if it's a regression of that, or something differant.
Comment 3•23 years ago
|
||
Hmm. This isn't bug 43567 - the fix for that bug means that the connection will time out after a time (which can be st by a hidden pref, if you want). MArking INVALID, since we will cache connections, and bug 43567 just meant that we didn't cache them forever If anyone does ever implment a "log out now" feature for session cookies and friends, I guess it could include open network connections, too.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 4•23 years ago
|
||
I noticed after going to a FTP site, then a few web sites (in a row in the same browser window), I checked netstat 5 minutes later, and not only was FTP still open, so was every site I had been to since then. tcp 0 0 my-ip:1054 miranda.org:ftp ESTABLISHED tcp 0 0 my-ip:1083 mothra.mozilla.org:http ESTABLISHED tcp 0 0 my-ip:1086 gila.mozilla.org:http ESTABLISHED tcp 0 0 my-ip:1085 gila.mozilla.org:http ESTABLISHED tcp 0 0 my-ip:1059 63.88.172.54:http ESTABLISHED tcp 0 0 my-ip:1063 63.88.172.54:http ESTABLISHED tcp 0 0 my-ip:1070 a207-229-152-8.dep:http ESTABLISHED tcp 0 0 my-ip:1071 a207-229-152-8.dep:http ESTABLISHED tcp 0 0 my-ip:1066 www.winntmag.com:http ESTABLISHED tcp 0 0 my-ip:1061 a207-229-152-42.de:http ESTABLISHED Are *all* of these HTTP connections supposed to be cached as well? For five minutes? The FTP site, for example, has only a 3 user limit. 5 minutes is quite a while to tie up one of those spots, if the user isn't going to end up getting anything. (And if they've left the page, they probably won't be.) Also notice that making a connection to ftp.dict.org, then one to miranda.org doesn't use the cached connection, though the IP is the same. Don't we want to base that on the IP? Should I file a seperate bug for this?
Comment 5•23 years ago
|
||
I don't want to use IP, because of round robin DNS issues. Besides, the ftp doesn't have access to teh IP directly (although it can get it, so thats not a major issue) HTTP is a separate issue, and theres another bug on that.
Comment 6•23 years ago
|
||
*** Bug 123129 has been marked as a duplicate of this bug. ***
VERIFIED: invalid. Jeremy, this is a pretty cool bug. In a perfect world, I would like to see our connection management be a bit more sophisticated.
Status: RESOLVED → VERIFIED
Summary: Mozilla not closing FTP connections → FTP connections held open by fqdn, not IP
Reporter | ||
Comment 9•22 years ago
|
||
Shouldn't it become an RFE then? Ideally, when no browser window is actively showing directory contents or downloading something from an ftp server, the control conncetion should be closed. Hitting 'back' should be able to show the directory listing via cache, without having the reconnect. I'd guess the percentage of times a user navigates an FTP site, goes to another HTTP site in the window, then ends up going back to the FTP site for NEW content is extremely small.
Reporter | ||
Comment 10•22 years ago
|
||
Reopening as RFE as requested.
Severity: major → enhancement
Status: VERIFIED → REOPENED
OS: Linux → All
Hardware: PC → All
Resolution: INVALID → ---
Summary: FTP connections held open by fqdn, not IP → [RFE] explicitly close FTP connections when no docshell actively displaying it
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 12•21 years ago
|
||
I noticed that even if you double click online/offline button, the ftp connection is not closed. a similar problem exists for IMAP.
Comment 13•21 years ago
|
||
I have noticed while doing testing w/ multiple clients, that more sites enforce a single connection/IP than I expected.
Summary: [RFE] explicitly close FTP connections when no docshell actively displaying it → close FTP control connections when no docshell actively displaying it
Comment 14•19 years ago
|
||
*** Bug 291832 has been marked as a duplicate of this bug. ***
Comment 16•9 years ago
|
||
rfe's for ftp features belong in addons these days..
Status: NEW → RESOLVED
Closed: 23 years ago → 9 years ago
Resolution: --- → WONTFIX
Updated•2 months ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•