Closed
Bug 51237
Opened 24 years ago
Closed 24 years ago
Mozilla keep-alive confuses multiple ports on same machine
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: wd, Assigned: darin.moz)
References
()
Details
(Keywords: relnote, testcase, Whiteboard: [dogfood-] relnote-user)
Attachments
(2 files)
1.36 KB,
patch
|
Details | Diff | Splinter Review | |
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.
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
Comment 3•24 years ago
|
||
I wonder if this is a problem with persistent connections.
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)
Comment 8•24 years ago
|
||
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].
Comment 10•24 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•24 years ago
|
||
*** Bug 57523 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
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
Reporter | ||
Comment 13•24 years ago
|
||
*** Bug 56958 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 14•24 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 machine. (side note: There is no workaround, and the problem is compounded by Mozilla's cache not keeping track of port numbers)
Comment 15•24 years ago
|
||
marking os all, nominating for mozilla0.9
Keywords: mozilla0.9
OS: Windows 98 → All
Comment 16•24 years ago
|
||
*** Bug 58393 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•24 years ago
|
||
*** Bug 54577 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 18•24 years ago
|
||
*** Bug 56189 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•24 years ago
|
||
*** Bug 56573 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
*** Bug 58871 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
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!:"
Comment 22•24 years ago
|
||
*** Bug 60052 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
This bug also occurs when submitting forms.
Comment 24•24 years ago
|
||
*** Bug 61649 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
*** Bug 61716 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 26•24 years ago
|
||
*** Bug 39214 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 27•24 years ago
|
||
*** Bug 62876 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
Isn't this the same bug as 43713?
Reporter | ||
Comment 29•24 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: 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?
Comment 30•24 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
Reporter | ||
Comment 31•24 years ago
|
||
*** Bug 39973 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 32•24 years ago
|
||
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.
Comment 33•24 years ago
|
||
*** Bug 65543 has been marked as a duplicate of this bug. ***
Comment 34•24 years ago
|
||
*** Bug 67301 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
see observations in bug 67301
Comment 36•24 years ago
|
||
*** Bug 67297 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 37•24 years ago
|
||
Sounds like a bug in our socket reuse policy.
Assignee: gagan → darin
Comment 38•24 years ago
|
||
*** Bug 66536 has been marked as a duplicate of this bug. ***
Comment 39•24 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•24 years ago
|
||
*** Bug 69051 has been marked as a duplicate of this bug. ***
Comment 41•24 years ago
|
||
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
Assignee | ||
Comment 42•24 years ago
|
||
Adding this bug to the mozilla 0.9.1 milestone. Time permitting, it might be fixed sooner.
Target Milestone: --- → mozilla0.9.1
Comment 43•24 years ago
|
||
*** Bug 69789 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 44•24 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
Assignee | ||
Comment 45•24 years ago
|
||
Assignee | ||
Comment 46•24 years ago
|
||
Setting milestone to 0.9 since we have a fix now.
Target Milestone: mozilla0.9.1 → mozilla0.9
Assignee | ||
Comment 47•24 years ago
|
||
r=gagan
Comment 48•24 years ago
|
||
looks good to me. sr=mscott
Assignee | ||
Comment 49•24 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 50•24 years ago
|
||
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
Comment 51•24 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 functions.
Comment 52•24 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•24 years ago
|
||
the type checking is me complaining that i have no good way to recognize whether the author meant the former or latter.
Assignee | ||
Comment 54•24 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?
Assignee | ||
Comment 55•24 years ago
|
||
*** Bug 43713 has been marked as a duplicate of this bug. ***
Comment 56•24 years ago
|
||
Comment 57•24 years ago
|
||
504 hits :-| As timeless says, we really need a grep tool which understands C ;-) Anyone volunteering to look at this lot? Gerv
Comment 58•24 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•24 years ago
|
||
Bug 70299 posted
You need to log in
before you can comment on or make changes to this bug.
Description
•