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)

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: