Closed Bug 43713 Opened 25 years ago Closed 25 years ago

http cache ignores the port field of URL

Categories

(Core :: Networking: Cache, defect, P2)

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

Tracking

()

Status:
VERIFIED DUPLICATE of bug 51237
Milestone:
mozilla0.9

People

(Reporter: kleist, Assigned: neeti)

References

(
URL
)

Details

(Keywords: verifyme, Whiteboard: [nsbeta3+])

(This may be related to bug 39973) RECIPE: 1. I enter "http://localhost" in the URL field at the top, or in the dialog "Open web location" which is displayed after ALT-L. This fails, which makes sense since I have no web server on port 80. 2. I enter "http://localhost:8080" which takes me to my Zope server. Fine. 3. If I enter "http://localhost" again, I'm obviously brought to port 8080. In fact, I can enter _any_ port number after the second colon and will _always_ come to 8080, e.g. "http://localhost:1234". Even if I enter e.g. "http://localhost:2316", a port on which I have another web server, I end up in 8080. I do like Zope, but in this case it's a bit too sticky ;-)
Reporter: Which build are you using when this happens? If this is brand new - related to the fix for bug 42841?
Build ID: 2000062321 (I thought that Bugzilla automatically collected this from Mozilla... )
Confirming bug (PC/Linux, build 2000062220). I tested this on a machine with Apache running on localhost port 80, and another HTTP server with different pages on port 8000. 1) Entering http://localhost/ loads the default Apache page. 2) Entering http://localhost:8000/ prints "Document http://localhost:8000/ loaded successfully" in the shell, but still displays the Apache page. 3) Restarting mozilla and connecting to http://localhost:8000 immediatly displays a different page. Upping serevity to major, because connecting to the correct port seems to be core functionality. See bug 39973 for another problem about port numbers being ignored. Mozilla seems to have some serious problems with host names and port numbers. Nominating for nsbeta2, nsbeta3. I think all these bugs with wrong hosts and port numbers should be fixed at least for nsbeta3. cc self.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta2, nsbeta3
When I say "all these bugs", I mean: bug 41486 "If unqualified hostname for home page, links don't work" bug 40849 "Mozilla forgets what web server to connect to" [nsbeta2-] bug 39973 "following link which includes a port ignores the port" and this bug. Maybe I should only nominate for one nsbeta at a time? Withdrawing nsbeta3 kw.
Keywords: nsbeta3
Oh this is great. I was looking for all these bugs since I recently fixed this as a fix for bug 42841. Andreas Thanks for summarizing all these bugs here.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I don't think this is fixed, I still see this problem with the latest linux builds. Try to switch between ports that have a web server and some that have not. The port is still "sticky"! Try this sequence in quick steps 1. http://localhost:90/ gives a connection refused 2. http://localhost:80/ works fine 3. http://localhost:90/ also works fine and displays port 80 page If you take some time between step 2 and 3 (say 2 minutes) step 3 gives a connection refused box as it should. Timeout?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Per PDT mtg today with gagan, moving from from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+] → [nsbeta2-]
Nominating for nsbeta3 then.
Keywords: nsbeta3
triage team: since we think this has to do with the bigger cache problems, we are plusing it. Reassign to neeti, cc'ing gagan.
Assignee: gagan → neeti
Status: REOPENED → NEW
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Neeti I can take this one next since I am done with the redirect bugs. Let me know if you are already working on it.
Assignee: neeti → dp
Priority: P3 → P2
Assigned.
Status: NEW → ASSIGNED
Hey guys. I cant reproduce this. Any help ? I made my apache server listen on ports 80 and 8080. Tried: - http://localhost:80 - http://localhost:8080 - http://localhost:90 The last request gave error. The second one succeeded. I could see from the code it going to the server alright.
Re-tested using the steps from my comments 2000-06-24 14:12. Build 2000080322 still shows the bug, but build 2000082708 does not have this problem. Seems to be fixed indeed. Anyone still seeing this?
I am going to mark this fixed so our testing will verify it again. Please reopen if any of you see this again.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
verif: Linux rh6 2000091108
Status: RESOLVED → VERIFIED
Build ID: 2000092909. RH 6.2 / glibc 2.1.3-21 (Related to bug 51237 ?) Reopening bug since I still get this behaviour: "http://localhost/" takes me nowhere which makes sense since I have no web server on port 80 "http://localhost:8080/" takes me to my web server on port 8080, fine "http://localhost" takes me to my web server on port 8080 "http://localhost:4711/" the same, in fact any port number will do, such as "999999999". However "9999999999" (ten nines) will be transmogriphed to "2147483647" (this should be raised as another bug, I guess?)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Yes, I think this could be related. There seem to be several bugs that seem to be along the lines of this one. For some reason, Mozilla doesn't always do as its told when it comes to ports. Sorry if this doesn't blong filed under this bug, but here's a simple test that demonstrates Mozilla confusing ports: http://dormcam.mine.nu:8080/moztest.html You should never get a red image. It should always be blue. With Mozilla I get a red image. Re-loading the page and/or clearing the cache can have an effect on which image is retrieved. (blue=correct=port 1234 ; red=wrong=port 8080) check it out!
*** Bug 55489 has been marked as a duplicate of this bug. ***
This isn't a Linux bug - it's reported for Windows as well. Changing OS to ALL.
OS: Linux → All
*** Bug 43523 has been marked as a duplicate of this bug. ***
*** Bug 56431 has been marked as a duplicate of this bug. ***
This problem is a cache problem. The second URL will work if you hit shift reload, or you set your cache to "NEVER". I used a packet trace to verify that the browser fails to load over the network when the url fails to go to the right page.
any progress on this? We're still seeing it here with current builds - we have multiple servers on the same host but different ports, and it's very very confusing in the way it behaves. Spelling the hostname differently (eg http://foo.dom.ain:port/, rather than http://foo:port/ is another workaround... but that's pretty annoying.
That's not even a good workaround be cause it only works with non-FQDN URLs...
Another publicly available example: http://docwhat.gerf.org:9673/ http://docwhat.gerf.org/ This is a very annoying bug and is potentially a security hole for any site that is multilayered (as some vhosting sites are). This bug exists as of Nightly build (from latest) 2000-12-18 (linux i686 gnu sea).
This should probably be obvious but it effects sites using framesets as well, for instance there are cases where we will build a site with a hidden frame (so that the url does not change and bookmarks are all at the home page) and the "index" for that frameset is on port 80, but one of the frame source's is on a different port, in which case that frame will not display correctly. In other words consider a frameset with 2 frames, the frameset index is on port 80, one frame also on port 80 (it displays correctly), the second frame is on port 8080 (it will give not found as in the other examples). Given that I do not know what code handles this I would assume that if you fix the problem for non-frame sites it will fix it for framed sites too, but thought it should be mentioned/checked. Can't wait until this one is done, only reason why I can't run Mozilla most of the time, all of my development is done on different ports (usually on the same site).
*** Bug 63412 has been marked as a duplicate of this bug. ***
dp is gone. reassigning to default component owner
Assignee: dp → neeti
Status: REOPENED → NEW
*** Bug 63483 has been marked as a duplicate of this bug. ***
Blocks: 51237
*** Bug 41513 has been marked as a duplicate of this bug. ***
This bug was marked to be fixed in a previous milestone but it didn't get fixed properly. Nominated for beta1.
Keywords: nsbeta1
Keywords: nsbeta2
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta3+]
--> Networking cache
Component: Networking → Networking: Cache
*** Bug 65247 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
improve summary
Summary: Port number in URL is "sticky" → http cache ignores the port field of URL
Sorry, didn't notice there was another bug to collect the dups.
Keywords: mostfreq
nominating for mozilla0.8
Keywords: mozilla0.8
*** Bug 65739 has been marked as a duplicate of this bug. ***
This bug should be resolved when the new cache code lands.
Target Milestone: --- → mozilla0.9
Should we be modifying the test cases so these problems get caught in testing next time?
Is this bug still around, now that bug 51237 is fixed? (the test cases are pretty much the same)
won't be surprised if darin's fix for the other one has fixed this bug too.
I meant to add... I'd like someone to verify if this is indeed fixed. (or prove otherwise)
Keywords: verifyme
Sounds like a dupe of bug 51237 to me. Only benc's comments suggest that this might actually be a cache bug. I'm going to go ahead and mark this as a dupe to get it off the radar screen. Please reopen if it's not actually fixed. *** This bug has been marked as a duplicate of 51237 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Recent builds pass the testcase in the comment by wdormann 2000-09-30 12:43
Status: RESOLVED → VERIFIED
Anyone can try this... but I'll do it if there is no update by tomorrow.
Keywords: mozilla0.8
I'm using a commercial build on Win98 2001-03-10-Mtrunk, and it works for me now. Many thanks, I got a lot of ports on a couple machines I use!
You need to log in before you can comment on or make changes to this bug.