Mozilla sends GET requests to wrong server




Networking: Cache
17 years ago
17 years ago


(Reporter: Target, Assigned: Darin Fisher)


Windows 98

Firefox Tracking Flags

(Not tracked)




17 years ago
This one's mostly random.

Occasionally mozilla will send GET requests to the wrong server. When you load a
page, one of the servers on it will sometimes wind up being the victim of this
bug, with subsequent GET(s) going to it instead of their proper destinations.

This usually seems to "stick" for a short while and then correct itself. When it
happens, the next few (2 or 3 usually) GETs will go to the same incorrect server
before GETs start being sent to the right places again.

For example, I loaded a page on my LAN webserver (nothing fancy, just a plain
page with a small navigation frame and a few images), and then hit my slashdot
bookmark. I got my webserver's 404. I tried the bookmark again and got my 404
again. Then I tried the reload button. My 404 again. I hit reload again and that
time slashdot came up.

When I checked apache's log, I found the following: - - [18/Nov/2000:01:22:41  -0500] "GET
HTTP/1.1" 404 303 "-" "Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001117" - - [18/Nov/2000:01:22:53  -0500] "GET
HTTP/1.1" 404 303 "-" "Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001117" - - [18/Nov/2000:01:23:02  -0500] "GET
HTTP/1.1" 404 303 "-" "Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001117"

I'm not using a proxy and moz isn't configured to use one, so my webserver
definately shouldn't have gotten those GETs.

Comment 1

17 years ago
Assignee: gagan → darin

Comment 2

17 years ago
Reporter: did you hit your slashdot bookmark before or after the page on your
LAN webserver finished loading?

Comment 3

17 years ago
Definately after. The page is pretty simple and loads in a split-second over the
100mbit LAN.

Comment 4

17 years ago
This bug's frequency seems to be steadily increasing, at least for me. Now I
can't go an hour without it happening at least once.

Well, at least now that it happens all the time I've been able to get more
detail. The incorrectly-addressed GET request can strike almost anything, not
just entire pages. A single frame from a page may be loaded from the wrong
server, or even a single image. The only pattern is that the server which
wrongly receives these GET requests is either the one you loaded your last page
from, or a server referenced by said page.

Also of note is that almost every time this bug hits, it lasts for exactly 3
page loads. If a page, frame or even an image is being requested from the wrong
server, attempting to load that item two more times (for a total of 3 times)
will result in the same request to the same incorrect server each time... but on
the 4th load, the request goes to the correct server and we get the document.

The only exception that I've found to this "3-load" rule is when the misdirected
GETs stick permanently. From that point on ALL future requests will go to one of
the recently-accessed servers, so unless you're actually surfing that particular
server you'll get a heaping helping of their 404 no matter where you try to go.
The only way to recover when this happens is to restart mozilla.

Comment 5

17 years ago
Over to cache for triage.
Component: Networking → Networking: Cache

Comment 6

17 years ago
Reporter is this still a problem in the latest nightlies?

Comment 7

17 years ago
Marking WORKSFORME due to lack of response. Reopen if this is still occuring in
the latest nightlies.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 8

17 years ago
It still happens here, with build ID 2001020804.  Tough to reproduce at will, 
but this usually works:

1. open random site
2. start surfing, go a few clicks deep
3. right-click on link and select "open in new window"
4. repeat from (2).  Problem will usually manifest itself within one or two 

I have tried reloading and retrying links, but for me, I always have to restart 
Mozilla to get it working.

You need to log in before you can comment on or make changes to this bug.