88839 - browser no longer able to access any sites after loging into projectplace

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P2)

Description

[Vladimir Ermakov]

Browser no longer able to access any sites after loging into projectplace.com
and navigating to one of the sites inside. The secure connection breaks, and
when you go to any site, even if it has nothing to do with project place
(bugzilla, yahoo...) netscape says that it cannot connect to that site. 
 This works on Linux Redhat 2001-07-02-06-trunk build but not on 
2001-07-02-04-windows 98

Steps to reproduce
1) goto URL
2) put in "[e-mail]" as username, "bugzilla" as password
3) Once inside click on "Bugzilla Test" project, and try to go to "Document Archive"

Expected Results: List of uploaded files
Actual Results: Secure connection is broken (notice the lock ikon in the bottom
right corner is either red, or unlocked) and you are no longer able to go to any
site on the web.

Note: this came out of bug 88814, most likely not related

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->PSM.

If it involves HTTPS, assign it to the PSM product, not Security:General.

Comment 2

[Stephane Saux]

-> ddrinan.
David. Can you try to replicate on windows.  I verified that it works for Linux
buildid 2001070204.

Comment 3

[John Unruh]

Worksforme on WinTN except for being able to view the List of uploaded files, 
probably because the page is using style sheets.

Comment 4

[Vladimir Ermakov]

This also works for me on windows 2000. Looks like this is win 98 only.

Comment 5

[Stephane Saux]

junruh: do you have a win98 machine to try this on?

Comment 6

[John Unruh]

Confirming the reporter's findings on Win98. WinNT is OK.

Comment 7

[Stephane Saux]

nsbranch

Comment 8

[David P. Drinan]

I think I know what the problem might be here: the nsNSSSocketInfo object that
is created for each SSL connection maintains a refenence to the necko
nsHttpConnection object. Since nsNSSSocketInfo is cached for lock icon/page info
purposes, the nsHttpConnection object is not being freed and as a result the SSL
socket is not being closed. On win98 this could be very bad over time since
socket resources are limited. I need to talk to the necko people to figure out
how to fix this.

Comment 9

[David P. Drinan]

I have discussed with dougt a possible solution. A patch to follow soon.

Comment 10

[David P. Drinan]

Attachment: Patch. Dougt, please review.

Comment 11

[Doug Turner (:dougt)]

This looks good to me.  r/sr=dougt

Comment 12

[David P. Drinan]

Doug, who else should review this before I check it into the trunk?

Comment 13

[David P. Drinan]

Fix checked into trunk.

Comment 14

[Gagan]

r=gagan fwiw...

Comment 15

[David P. Drinan]

Fix checked into branch.

Comment 16

[Stephane Saux]

*** Bug 90625 has been marked as a duplicate of this bug. ***

Comment 17

[Rangan Sen]

I tested this out on a win98 machine. Seems to be working fine now.

Comment 18

[Julz]

Thanks for fixing this as this is the only reason I'm using IE at the moment. 
Sorry about the duplicate bug 90625.  I did a search for PSM and secure and got
nothing so I assumed it had not been logged yet.
Win98 runs out of TCP connections at about 80 connections.

Comment 19

[Julz]

I just found out at
http://support.microsoft.com/support/kb/articles/Q158/4/74.ASP that it is
possible to increase the number of conncurrent connections via TCP with the
following entry in the win98 registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\MaxConnections
(string type). Default is 100

Although this is not the best way to solve problems that are bugs, but it would
have been a temporary fix but would eventually cause win98 to run out of memory.

Comment 20

[John Unruh]

Verified on 7/15 win98 branch.