Closed Bug 248253 Opened 20 years ago Closed 17 years ago

hanging connections leads to inability to load any connections

Categories

(Core :: Networking, defect)

1.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: cspandex, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 I'm not quite technical enough to describe this so bear with me. On myspace.com (and probably others), sometimes when the server is overloaded the image server will hang, which causes a strange reaction in Firefox. This is generally fixed in other browsers (like IE) by simply reloading the page. The images load, everything is fine. However, I've noticed in Firefox that when the connections begin hanging, it seems like it busies some socket(?) and is afterwards unable to make any new connection to that image. It gets to a point where images are not loading at all. Reloading does nothing, closing and reopening tabs does nothing. Yet it's not a site issue, because launching another browser side by side shows that all images still load fine. Its 100% in firefox and nowhere else. I'm wondering, is there something about concurrent connections that might be left open and blocked on connection errors? Reproducible: Sometimes Steps to Reproduce: Sorry, its a bit difficult to reproduce.
I know what you mean... I have similar problems with entire pages. Best chance for it is on my own webserver, where I get stats over a socket via php what takes some time to send the page to the browser. But unfortunately the page is on a private space ( http://stats.flirtcom.net ). 1. Open such a page with a big delay (perhaps also server-related) 2. Klick on a link on that Page to open another page before the first page has loaded Neither frist nor second page loads while there is no problem when you wait long enough. I've encountered that problem on several other slow pages, but there has to be some more conditions I have to figure out perhaps with sniffering the traffic between me and the server... Perhaps some permanent socket connections fail to proceed when a transaction didn't finished. IE has no such Problem (perhaps resets such connections). Perhaps also some servers do better prevent such conflicts on their side... I know that bug now for months, but I can't give you a 100% reproduction and never mentioned it (perhaps I should put a public testcase with an almost 100% hit rate on my server...)
Seems to be a network issue, although I may be wrong...
Component: General → Networking
Product: Firefox → Core
QA Contact: general → benc
Version: unspecified → 1.0 Branch
Reproducible steps: 1. go to www.flirtcom.net and you will see the portal page 2. click on "Members" then "Chat" as fast as you can, before the "Members" page tries to render If you end up with the "Chat"-Page, try again If you end up with an endless loading-mouse cursor, you encountered the bug and can make further observations: - No other link will work on that page from now on - Open another tab/window and type www.flirtcom.net: also nothing seems to work here - Close the first testwindow (but leave some other firefox windows open) and also try to open a page on that server: still no reaction - Close all firefox windows (restart firefox): now the pages work again - Try the same thing with IE: no such effect appears
Correction: IE also seems to have that problem now, and since I've sniffered the traffic, it's obvious that it is a "Connection: Keep-Alive" Bug either on some Apache-Server-sites or browsers with that feature. Traffic seems to stop in the middle of the first page you load, and the browser seems to send no further "GET ... HTTP/1.1 to the server (I don't know if that would help)
Assignee: bross2 → nobody
QA Contact: benc → networking
WFM per reporter "i dont seem to have this problem anymore"
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.