Networking: HTTP
2 years ago
2 years ago


(Reporter: lesliewu2008, Unassigned, NeedInfo)


38 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

536.16 KB, image/png


2 years ago
Created attachment 8714214 [details]

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.


2 years ago
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Can you send me a http log:

Thank you.
Flags: needinfo?(lesliewu2008)

Comment 2

2 years ago
Created attachment 8714629 [details]
Flags: needinfo?(lesliewu2008)

Comment 3

2 years ago
http log attached.

Comment 4

2 years ago
we find that this issue is related with preference "", which is set to 5 by default. If it is set to a bigger value like 60, this issue will not occur.

Comment 5

2 years ago
I am working with bug reporter on this bug....

more information:
As mentioned in last post,  we finally found change preference "" 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 "", 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)

Comment 7

2 years ago
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.


2 years ago
Attachment #8714629 - Attachment is obsolete: true


2 years ago
Group: core-security

Comment 8

2 years ago
need to close this bug. 
please refer to another bug which will be soon be reported and visible publicly
Last Resolved: 2 years ago
Resolution: --- → INVALID

Comment 9

2 years ago
for problem refereed in this bug , pls refer to the following  bug :


2 years ago
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

Comment 11

2 years ago
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.