Last Comment Bug 117875 - close FTP control connections when no docshell actively displaying it
: close FTP control connections when no docshell actively displaying it
Product: Core
Classification: Components
Component: Networking: FTP (show other bugs)
: Trunk
: All All
-- enhancement with 1 vote (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: benc
: Patrick McManus [:mcmanus]
: 291832 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2002-01-02 22:00 PST by Jeremy M. Dolan
Modified: 2015-12-18 06:31 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Jeremy M. Dolan 2002-01-02 22:00:18 PST
I connected to in Mozilla, saw I wanted a file, so I
started a real FTP client. (Mozilla's downloading doesn't work, seperate issues).

---- Connecting to ( 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.
Comment 1 User image Matthias Versen [:Matti] 2002-01-02 23:32:18 PST
Please ALWAYS add the build ID in a bug report.

dupe of bug 43567 ?
Comment 2 User image Jeremy M. Dolan 2002-01-02 23:46:11 PST
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
Comment 3 User image Bradley Baetz (:bbaetz) 2002-01-10 04:06:54 PST
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.
Comment 4 User image Jeremy M. Dolan 2002-01-10 04:33:29 PST
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         ESTABLISHED
tcp        0      0 my-ip:1083 ESTABLISHED
tcp        0      0 my-ip:1086   ESTABLISHED
tcp        0      0 my-ip:1085   ESTABLISHED
tcp        0      0 my-ip:1059       ESTABLISHED
tcp        0      0 my-ip:1063       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   ESTABLISHED
tcp        0      0 my-ip:1061 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, then one to
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 User image Bradley Baetz (:bbaetz) 2002-01-10 06:13:04 PST
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 User image Matthias Versen [:Matti] 2002-02-02 09:16:33 PST
*** Bug 123129 has been marked as a duplicate of this bug. ***
Comment 7 User image benc 2002-06-07 19:33:46 PDT
I'll verify this if I can find out what the ftp timeout is...
Comment 8 User image benc 2002-08-28 16:02:58 PDT
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.
Comment 9 User image Jeremy M. Dolan 2002-08-28 17:06:16 PDT
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.
Comment 10 User image Jeremy M. Dolan 2002-08-30 21:03:25 PDT
Reopening as RFE as requested.
Comment 11 User image Bradley Baetz (:bbaetz) 2002-09-16 22:09:20 PDT
ftp -> dougt
Comment 12 User image cybernytrix 2003-03-17 07:48:45 PST
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 User image benc 2003-03-18 09:59:50 PST
I have noticed while doing testing w/ multiple clients, that more sites enforce
a single connection/IP than I expected.
Comment 14 User image Frank Wein [:mcsmurf] 2005-05-03 12:45:49 PDT
*** Bug 291832 has been marked as a duplicate of this bug. ***
Comment 15 User image Doug Turner (:dougt) 2007-10-08 16:22:18 PDT
mass reassigning to nobody.
Comment 16 User image Patrick McManus [:mcmanus] 2015-12-18 06:31:27 PST
rfe's for ftp features belong in addons these days..

Note You need to log in before you can comment on or make changes to this bug.