Mozilla keep-alive confuses multiple ports on same machine

VERIFIED FIXED in mozilla0.9



19 years ago
18 years ago


(Reporter: wd, Assigned: darin.moz)


({relnote, testcase})

relnote, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [dogfood-] relnote-user, URL)


(2 attachments)



19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20000901
BuildID:    2000090110

When I load up the above URL, lots of times the video feed does not appear.

Reproducible: Sometimes
Steps to Reproduce:
1.Go to
2.Click in the location box at the top and press enter several times (waiting
each time...  essentially re-loading the page)
3.Right click in the main frame and click "Reload Frame" several times

Actual Results:  It appears that about 90% of the time when doing step 1 or 2,
the video feed does not come up.    With step 3, it's maybe 20% of the time that
it works.

Expected Results:  The video feed comes up each time, every time, without

For some reason, when I go to (which is
the main frame containing the video), it seems to work all the time.   It's only
when I go to the framset page when I
notice the problem with the picture not coming up.

Comment 1

19 years ago
I think this bug may be related to bug 48203

Comment 2

19 years ago
Ok, I've got more info which should really help out here.

The web site is hosted on port 8080.   The video feed comes from port 2047.
Whenever the video feed does not come up, it's when Mozilla tries to pull the
stream from port 8080!

Part of my source that displays the video feed is:

Looking in my server logs (run on port 8080) I get on occasion:   [04/Sep/2000:10:59:12 "GET /cgi-bin/video 404
It looks like when a specific port is specified in the HTML, Mozilla will on
occasion ignore that and use the default port specified in the URL instead.
Severity: normal → major
Summary: JScript / Jpeg push feed works only intermittently → Mozilla confuses multiple ports on same machine

Comment 3

19 years ago
I wonder if this is a problem with persistent connections.

Comment 4

19 years ago
*** Bug 54174 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
OK, here's a real simple testcase:

With Netscape, I get a blue image from port 1234.  This is the correct behavior.
 With Mozilla, I get a red image from port 8080.   Mozilla seems to
intermittently ignore the port specified in the HTML.

Comment 6

19 years ago
Note:   This is a quite intermittent bug.   Re-loading the page several times, 
and also clearing your cache can effect which image you see.  (red or blue)

Comment 7

19 years ago
*** Bug 51301 has been marked as a duplicate of this bug. ***

Comment 8

19 years ago
This happens to me as well. A renowned MAME ROM site ( serves
screenshots of the games from a different port. Mozilla refuses to show them at
first. Reloading generally fixes this.

Comment 9

19 years ago
I got the red image the first time i went there 10/06-04 w32.

I often run 3 web servers on my computer, or maybe  3 http ports forwarded to 
different places.  Toggling the cache radio selection in preferences sometimes 
makes it easier to toggle from red to blue, but not reliably. And I need to 
file a bug requesting clarification of that text [it doesn't make sense].
Keywords: dogfood, relnote, relnoteRTM, testcase

Comment 10

19 years ago
This sounds like a pretty bothersome bug... but I don't think it stops most
day-to-day use of N6... so I can't push for dogfood focus by Netscaper's.
Marking dogfood-minus.

Please don't misunderstand: This is a bad bug (someone is not looking at the
port number). 
Whiteboard: [dogfood-]

Comment 11

19 years ago
*** Bug 57523 has been marked as a duplicate of this bug. ***
Marking relnote-user, but someone is going to have to describe exactly what the 
problem is, in layman's terms.

Whiteboard: [dogfood-] → [dogfood-] relnote-user

Comment 13

19 years ago
*** Bug 56958 has been marked as a duplicate of this bug. ***

Comment 14

19 years ago
In layman's terms:   (Assuming a layman knows what a "port" is)

When a specific port is specified within a web page, Mozilla will often ignore 
it and use the current port instead.     Mozilla will also run into trouble 
when there are multiple web sites addressed by different ports on the same 

(side note:   There is no workaround, and the problem is compounded by 
Mozilla's cache not keeping track of port numbers)
marking os all, nominating for mozilla0.9
Keywords: mozilla0.9
OS: Windows 98 → All

Comment 16

19 years ago
*** Bug 58393 has been marked as a duplicate of this bug. ***

Comment 17

19 years ago
*** Bug 54577 has been marked as a duplicate of this bug. ***

Comment 18

19 years ago
*** Bug 56189 has been marked as a duplicate of this bug. ***

Comment 19

19 years ago
*** Bug 56573 has been marked as a duplicate of this bug. ***

Comment 20

19 years ago
*** Bug 58871 has been marked as a duplicate of this bug. ***

Comment 21

19 years ago
the demo images at are yet an excample of
this bug. None of the images will display.
(Links in right column under "Try DIRT online!:"

Comment 22

19 years ago
*** Bug 60052 has been marked as a duplicate of this bug. ***

Comment 23

19 years ago
This bug also occurs when submitting forms.

Comment 24

19 years ago
*** Bug 61649 has been marked as a duplicate of this bug. ***


19 years ago
Keywords: mostfreq

Comment 25

19 years ago
*** Bug 61716 has been marked as a duplicate of this bug. ***

Comment 26

19 years ago
*** Bug 39214 has been marked as a duplicate of this bug. ***

Comment 27

19 years ago
*** Bug 62876 has been marked as a duplicate of this bug. ***

Comment 28

19 years ago
Isn't this the same bug as 43713?

Comment 29

19 years ago
They look very similar.   The one thing I noticed with bug 43713 is that it 
involves going to a particular URL, and then after that going to the same URL 
but with a port number.  i.e.   http://foo and then http://foo:8080

Well, I can totally delete my Mozilla cache, load up Mozilla and then go to:
and it will pull the image from the wrong port.     It's a one-step test.   Is 
bug 43713 the same as this?

Comment 30

19 years ago
going to localhost:8080/ => icq doorbell. going to localhost/ => tomcat 
webserver. going to localhost:8080/ again => tomcat webserver [which is not on 
:8080]/ [reload causes doorbell]
going to http://localhost:8080/right.html*16473 [which should be on icq] 
results in
HTTP Status 404 - /right.html*16473
The requested resource (/right.html*16473) is not available.
which is a tomcat error message. [reload causes correct page]

I suggest we leave the two bugs separate. Use this one to collect dupes and 
that one to collect fixes. Otherwise that one will have too much spam.

Has anyone succeeded in getting mozilla stuck on a port other than :80 ? 
Depends on: 43713

Comment 31

19 years ago
*** Bug 39973 has been marked as a duplicate of this bug. ***

Comment 32

18 years ago

Yes, it is not necessarily port 80.   In my test at: , mozilla often pulls an image from 
port 8080, even though the image is specified to come from port 1234

It appears that even when a port is specified explicitly, Mozilla will often 
just use the port# that the current page is on.

Comment 33

18 years ago
*** Bug 65543 has been marked as a duplicate of this bug. ***

Comment 34

18 years ago
*** Bug 67301 has been marked as a duplicate of this bug. ***

Comment 35

18 years ago
see observations in bug 67301 

Comment 36

18 years ago
*** Bug 67297 has been marked as a duplicate of this bug. ***

Comment 37

18 years ago
Sounds like a bug in our socket reuse policy.
Assignee: gagan → darin

Comment 38

18 years ago
*** Bug 66536 has been marked as a duplicate of this bug. ***

Comment 39

18 years ago
I had a problem with this bug getting to my Linuxconf web-admin page( Running 
on port 98). I got the first page, but couldnt open the login link.
First I typed http://localhost:98/ in the location bar, and got the intro-page, 
but when I clicked the link to http://localhost:98/html:/, nothing came up.

Then, I was using Linuxconf 1.19 and when I upgraded to 1.24, it worked...

Comment 40

18 years ago
*** Bug 69051 has been marked as a duplicate of this bug. ***

Comment 41

18 years ago
We have efacts installed
locally and this prevents us from using Mozilla/NS6 with the application.  It
will start up a session, but then when it needs to pull data from another port
it refuses to continue (or acts like it's finished).  I see this in both the
nightlies for Linux and Windows.  This is probably the only bug that is
preventing us from moving away from IE5/NS4.x

Comment 42

18 years ago
Adding this bug to the mozilla 0.9.1 milestone.  Time permitting, it might be
fixed sooner.
Target Milestone: --- → mozilla0.9.1
*** Bug 69789 has been marked as a duplicate of this bug. ***

Comment 44

18 years ago
Yes, it does appear that keep-alive is the determining factor here!   If
keep-alives are disabled, the test URL for this page works fine.    Otherwise,
Mozilla gets confused.
Adding "keep-alive" to the summary....
Summary: Mozilla confuses multiple ports on same machine → Mozilla keep-alive confuses multiple ports on same machine

Comment 45

18 years ago

Comment 46

18 years ago
Setting milestone to 0.9 since we have a fix now.
Target Milestone: mozilla0.9.1 → mozilla0.9

Comment 47

18 years ago

Comment 48

18 years ago
looks good to me.

Comment 49

18 years ago
Fix checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED
Can someone with better knowledge of regexps than me grep the codebase for 
bracket .* == .* nobracket but question-mark  .* colon .* bracket ?
(see the patch for what I mean.)

If this sort of problem is anywhere else, it's a bug too. And we get to fix lots 
for free, rather than spending six months tracking them down (like this one.)


Comment 51

18 years ago
\(.*==[^)?]*\?[^:]*:.*\) is about the best i could find.

but it really needs to check for object typing. a==b?c:d is sometimes meant as 
(a==b)?c:d [correct], or a==(b?c:d). the best way i've found to think about 
them is comparing the type of a to c/d vs. b. unfortunately types come from 

Comment 52

18 years ago
timeless: or we could just change add parentheses to *all* instances of the 
a == b ? c : d pattern, and not worry about type checking.  Then we'd be 
replacing most instances with (a == b) ? c : d, and a few buggy ones would be 
replaced with a == (b ? c : d).  It's clear from this bug that the prededence 
rules aren't obvious, so adding parentheses in both cases should make code 
clearer.  See also bug 67635, '[rfe] "readability" keyword', which would 
hopefully encourage people to make this type of change.

Comment 53

18 years ago
the type checking is me complaining that i have no good way to recognize 
whether the author meant the former or latter.

Comment 54

18 years ago
I agree with timeless.  Each case would have to be handled on an individual
basis.  Using a regexp, however, would reveal suspicious expressions, and
using cvs blame we could contact the relevant owners... sound good?

Comment 55

18 years ago
*** Bug 43713 has been marked as a duplicate of this bug. ***
504 hits :-| As timeless says, we really need a grep tool which understands C 

Anyone volunteering to look at this lot?


Comment 58

18 years ago
Gerv, Darin, Timeless: what do you think of making a new bug for searching for 
and parenthesizing the a==b?c:d pattern, in order to avoid letting this bug 
morph too much?  Please cc me on the new bug if you do :)

Comment 59

18 years ago
Bug 70299 posted

Comment 60

18 years ago
verified WinNT 2001052204

Comment 61

18 years ago
Keywords: relnoteRTM
You need to log in before you can comment on or make changes to this bug.