Closed Bug 51237 Opened 25 years ago Closed 24 years ago

Mozilla keep-alive confuses multiple ports on same machine

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: wd, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: relnote, testcase, Whiteboard: [dogfood-] relnote-user)

Attachments

(2 files)

Fixes the problem
1.36 KB, patch
Details | Diff | Splinter Review
My attempt using Timeless' regexp on 2001-02-22 source.
48.61 KB, text/plain
Details
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 http://dormcam.mine.nu:8080/index1.shtml 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 exception. For some reason, when I go to http://dormcam.mine.nu:8080/main.shtml (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 http://dormcam.mine.nu:8080/index1.shtml when I notice the problem with the picture not coming up.
I think this bug may be related to bug 48203
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: <IMG SRC=http://dormcam.mine.nu:2047/cgi-bin/video> Looking in my server logs (run on port 8080) I get on occasion: xxx.xxx.xxx.xxx [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
I wonder if this is a problem with persistent connections.
*** Bug 54174 has been marked as a duplicate of this bug. ***
OK, here's a real simple testcase: http://dormcam.mine.nu:8080/moztest.html 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.
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)
*** Bug 51301 has been marked as a duplicate of this bug. ***
This happens to me as well. A renowned MAME ROM site (http://www.mame.dk) serves screenshots of the games from a different port. Mozilla refuses to show them at first. Reloading generally fixes this.
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].
URL: http://dormcam.mine.nu:8080/index1.shtml → http://dormcam.mine.nu:8080/moztest.html
Keywords: dogfood, relnote, relnoteRTM, testcase
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-]
*** 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. Gerv
Whiteboard: [dogfood-] → [dogfood-] relnote-user
*** Bug 56958 has been marked as a duplicate of this bug. ***
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 machine. (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
*** Bug 58393 has been marked as a duplicate of this bug. ***
*** Bug 54577 has been marked as a duplicate of this bug. ***
*** Bug 56189 has been marked as a duplicate of this bug. ***
*** Bug 56573 has been marked as a duplicate of this bug. ***
*** Bug 58871 has been marked as a duplicate of this bug. ***
the demo images at http://purrr.infopreneur.com/dirt/ are yet an excample of this bug. None of the images will display. (Links in right column under "Try DIRT online!:"
*** Bug 60052 has been marked as a duplicate of this bug. ***
This bug also occurs when submitting forms.
*** Bug 61649 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
*** Bug 61716 has been marked as a duplicate of this bug. ***
*** Bug 39214 has been marked as a duplicate of this bug. ***
*** Bug 62876 has been marked as a duplicate of this bug. ***
Isn't this the same bug as 43713?
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: http://dormcam.mine.nu:8080/moztest.html and it will pull the image from the wrong port. It's a one-step test. Is bug 43713 the same as this?
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
*** Bug 39973 has been marked as a duplicate of this bug. ***
Timeless: Yes, it is not necessarily port 80. In my test at: http://dormcam.mine.nu:8080/moztest.html , 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.
*** Bug 65543 has been marked as a duplicate of this bug. ***
*** Bug 67301 has been marked as a duplicate of this bug. ***
see observations in bug 67301
*** Bug 67297 has been marked as a duplicate of this bug. ***
Sounds like a bug in our socket reuse policy.
Assignee: gagan → darin
*** Bug 66536 has been marked as a duplicate of this bug. ***
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...
*** Bug 69051 has been marked as a duplicate of this bug. ***
We have efacts http://www.factsandcomparisons.com/efactsintro.asp 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
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. ***
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
Setting milestone to 0.9 since we have a fix now.
Target Milestone: mozilla0.9.1 → mozilla0.9
r=gagan
looks good to me. sr=mscott
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 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.) Gerv
\(.*==[^)?]*\?[^:]*:.*\) 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 functions.
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.
the type checking is me complaining that i have no good way to recognize whether the author meant the former or latter.
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?
*** 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? Gerv
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 :)
Bug 70299 posted
verified WinNT 2001052204
Status: RESOLVED → VERIFIED
-relnoteRTM
Keywords: relnoteRTM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: