Closed Bug 1244617 Opened 9 years ago Closed 9 years ago

invalid bug

Categories

(Core :: Networking: HTTP, defect)

38 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: lesliewu2008, Unassigned, NeedInfo)

References

Details

Attachments

(1 file, 1 obsolete file)

(deleted), image/png
Details
Attached image xH54j.png (deleted) —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150514102509 Steps to reproduce: attached wireshark log. client is a Firefox 38 on a win 7 system. problem is: why client sent a FIN,ACK after 5 seconds? It is because after wait 5 seconds, nothing come from server? if my guess true, is there any setting in Firefox to extend this, as server is slow and 5 seconds is short. if not true, is it just because client (firefox browser )has some issue which cause client to sent FIN ,ACK to close connection? OR could be some server issue? OR firefox issue? we encounter this issue intermittently when server performance is slow. Server people say it is not a server issue, and client people say it is not application client issue? Could it be possible just firefox issue, or some extension on firefox cause client sent FIN,ACK? the most important question: from the wireshark, it is reasonable that server people say no problem at server because client issued a fin,ack? Is there any firefox setting to change this behavior? thanks in advance for anybody who knows TCP/IP. Actual results: The performance in UI is somewhat similar to clicking on "x" on the right side of the url bar during page loading and leave a blank page on the browser content. Expected results: page is fully loaded as normal, not a blank page.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Attached file log.txt (obsolete) (deleted) —
Flags: needinfo?(lesliewu2008)
http log attached.
we find that this issue is related with preference "network.http.network-changed.timeout", which is set to 5 by default. If it is set to a bigger value like 60, this issue will not occur.
I am working with bug reporter on this bug.... more information: As mentioned in last post, we finally found change preference "network.http.network-changed.timeout" to bigger value can solve this bug. as we spend lots of time in checking this bug, following is our other findings which may help in analyze the bug: definition of this bug: we see [FIN,ACK] sent from firefox to server to trigger stop the connection. we use two different login page to reproduce this. (both login page need >10s to login). what it appears from user side is that after click sign in in our login page, page begin to load, but after a while , it suddenly stopped to load the page. (in wireshark log check, we see [FIN,ACK] sent from firefox to server) 1. the bug seems is quite intermittent, for manually reproduce it, we found that only certain VM in our cloud can reproduce it. we didn't reproduce this issue on our local PC 2. for firefox version, although this preference we found "network.http.network-changed.timeout", was introduced in firefox 36, but during our huge testing , in all (>1000 cases), it shows that we can't reproduce on the following firefox version: 24ESR, 31 ESR, 34, 35, 36. we can reproduce on the following firefox version: 37,38, 40. we only tried the above firefox version, for any firefox version, i use its last available small version. 3. we also found some wired things that in most our reproduced evn, when reproduced, firefox sent [fin,ack] after it doesn't receive anything from server after around 5 seconds. (as we didn't change the default setting before. ) but on one system(with the same default setting ), Firefox sent [FIN,ACK] after 10 seconds, even this preference is set to 5 on the machine. while for all reproduced machine, if this preference is set bigger enough (like 500), the issue gone.
This is network change events. Need info bagder.
Flags: needinfo?(daniel)
for "network change event" do you mean that the client(which has installed firefox) changed network connection. or can also be, firefox itslef, changed from 1 network to another network (for example , by change proxy)? seems there is no network change in our env when we reproduce the bug. we can check with our IT people related to "network change". in one our example which has reproduced this bug, we have used a most easy login page, which was build for this bug on purpose, the login does nothing, but after user click login, server side just wait 20 seconds, and then output such text. when we use a testing tool to automate such process run >100 times continuously , we can produce it intermittently. some times around 1 in 100, some times, a little bigger chance. we have a very complex login page, during login, lots of js run and have redirection, and in total ,takes >10s to login. for this case, it can reproduce some times. also as i mentioned, we see this bug only since firefox 37. i didn't see we involve net work change . we didn't change firefox proxy. we also didn't change system's network.
Attachment #8714629 - Attachment is obsolete: true
Group: core-security
need to close this bug. please refer to another bug which will be soon be reported and visible publicly
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
for problem refereed in this bug , pls refer to the following bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1245059
Summary: Firefox 38 sent FIN,ACK after server ack an http get → invalid bug
Flags: needinfo?(daniel)
Resolution: INVALID → FIXED
Group: core-security → core-security-release
I am not sure why is this marked as core-security. There is the same bug but not marked as security? Maybe there was just some private information here, if that is the case we can marked only that as private?
Flags: needinfo?(lesliewu2008)
Resolution: FIXED → INVALID
sorry, marked as "core-security" may not appropriate. what we want is to make this bug can't see publicly, in any kinds of way. Yes,can do anything to this bug, only needs is that this bug don't expose to more. if possible, delete this bug or remove all bug attached file on this bug will be best for us
Flags: needinfo?(lesliewu2008)
(In reply to lesliewu2008 from comment #11) > what we want is to make this bug can't see publicly, in any kinds of way. > > Yes,can do anything to this bug, only needs is that this bug don't expose to > more. Bugs are ultimately made public, as stated in the bugzilla privacy policy when you signed up for your account. We have a limited ability to remove information from the database (through manual intervention). What is the reason this bug needs to remain hidden?
Flags: needinfo?(lesliewu2008)
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: