Closed Bug 140530 Opened 22 years ago Closed 21 years ago

Website content (images) mixed up (caches constantly corrupted) with pipelining

Categories

(Core :: Networking: HTTP, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 195746
Future

People

(Reporter: janusfury, Assigned: darin.moz)

References

Details

(Keywords: qawanted, Whiteboard: no patch, needs investigation [pipelining])

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020426
BuildID:    2002042608

If I click a link to open a page, usually during the download of one page, a
large portion of my cache becomes corrupted. Images are randomly swapped, and
HTML pages are replaced with images. The only way to correct  this is to empty
the entire cache and then reload the page entirely. This persists if i close the
window and open again - I HAVE to empty the cache and reload.

Reproducible: Always
Steps to Reproduce:
1. Open a page full of images and text.
2. Do not allow it to download, click other links immediately (preferably ones
that open popup menus)

Actual Results:  Images were swapped and not downloaded, corrupted... pages
would not display, or were displayed as images from the previous page.

Expected Results:  Mozilla should have opened aforementioned link, and displayed
it properly.

This is a very, very bad cache problem. I've been having it in the nightly
builds from the past couple weeks.
BTW, I posted a bug involving part of this one recently, and it was marked as a
duplicate of a completely unrelated bug. Please do me a favor and check this one
out thouroughly - it makes the browser almost completely unusable when it shows
up. This bug has sent me running back to IE multiple times recently. :)
some questions..

-Are you using a proxy?
-Are you sharing the profile with for instance an installation of NS6.* ?
-Did you perform a clean installation? (After uninstalling possibly older
version of Mozilla)

The dup'ed bug you refer to - bug 139903 - was made dup of bug 137179, again
dup'ed against bug 121084. Both have to do with cache corruption. This may still
be a dup.
And also: What is your cache pref setting?
(Is it set to compare "Every time I view the page" ?)
I've used "every time I view the page" and "when the page is out of date" - this
problem occurs with both.

I'm not using a proxy.

I never even created a profile, I would never let Netscape 6 onto my machine :P

This is a somewhat clean installation - I started with 0.99 and then installed a
few nightly builds, leading up to this one.
CONFIRMED.

Linux (Mandrake 8.1) CVS trunk custom build. Cache is set to 4096KB/50000XB;
Compare every time I view the page. I have tried this both with and without a
proxy, I believe I've seen it in both cases. I have 2GB free. I see it
especially with images on large, frequently refreshing dynamically generated
pages. It started happenening within the last month. Unfortunately I have no
reliable way to reproduce it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 143200
Possible contributing factor: there are NetApp NetCache boxes on the networks
that Ian and I use.

Ian - Via: 1.1 cache-haw (NetCache NetApp/5.1R2D14)
me -  Via: 1.1 webcacheB12 (NetCache NetApp/5.2.1R1D3)
Should this really be blocking bug 143200?  From what I've read it seems that
this hasn't even been confirmed on a branch build, and therefore shouldn't
impact RC3.
I also saw this with Squid as an (explicit) caching proxy earlier today. At
least, I think I did. I didn't clear my cache, so it may have been a continuing
side-effect from when I was on the NetCached network.
gordon/darin, any thoughts on what is going on here or what the fix might look like?
Whiteboard: no patch
Whiteboard: no patch → no patch, needs investigation
People who are seeing this bug, please give the following information:

   * HTTP settings (Prefs->Advanced->HTTP Networking)
   * Proxy setting (Prefs->Advanxed->Proxies)
   * Cache compare setting (Prefs->Advanced->Cache)

Check if you're going through a transparent proxy:

    telnet www.mozilla.org 80
    HEAD / HTTP/1.0

Look for a "Via:" header coming back.

In my case:

  HTTP Direct: 1.1, Keep-Alive, Pipelining
  HTTP Proxy: 1.1, Keep-Alive
  Proxy: none
  Cache: "When the page is out of date"
  Via: 1.1 webcacheM05 (NetCache NetApp/5.2.1R1D8)
tor: can you try disabling pipelining?  since you are using a transparent proxy,
mozilla treats your connection like a direct connection, which means that
mozilla will try to pipeline requests.  your transparent web proxy might have
issues with pipelined requests.
Whiteboard: no patch, needs investigation → no patch, needs investigation [pipelining]
I also had pipelining enabled. Assuming that fixes it, does it mean netcache has
issues with pipelining, or is it us who have issues with pipelining?
hard to say for sure... since our pipelining implementation seems to work fine
in most cases, and since mozilla is the first popular browser (does amaya
count?) to implement pipelining, i'd guess that these transparent proxies may
have problems handling pipelined requests.  in order to understand what going on
we'd have to take a closer look at the packets going back and forth... or
perhaps take a look at the proxy server logs (anyone have access to these?).
Turned off pipelining and cleared the cache - no problems so far.
If this is a pipelining problem then we should pull it off the RC3 list. We've
already got a bug (bug 144607) about release noting or obscuring the pref. 
assuming this fixed by diabling pipelining (experimental feature).
removing from the RC3 list
sounds like it might be good to release note if we have a "known issues
with pipeling section.

chris h.
No longer blocks: 143200
I've had the cache go bad for me every now and then the last year. Once the
cache is clear the pages are fine again.

I've got this problem 3 times the last 2 days with moz 1.0rc3. In two of the
cases the wrong image was displayed on a page, and the third all the page in a
frame was gone and böank instead of a lot of contents.

I allways install rpm:s, and I have pipelining on, but i've had this problem for
a long time (before pipelining). Most of the time it's weeks between the
problems but there is definitly something that is wrong.

I've not filed a bug before since i've not been able to reproduce it. And I
can't reproduce it now either, I just wanted to say that there are more people
with this problem.
Darin... 

Could you post the relnote here before release? I'm in a nitpicky mood. ;)

-jim
Jim: take a look at the current release notes for mozilla 1.0 rc3.
Server side issues with HTTP pipelining.  Changing component to HTTP to let
darin decide how he wants to resolve it.
Assignee: gordon → darin
Component: Networking: Cache → Networking: HTTP
QA Contact: tever → httpqa
reducing severity since pipelining is disabled by default and because there is
IMO a sufficient enough warning in the preferences panel.
Severity: critical → normal
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Is this a duplicate of bug 134517? That one describes similar symptoms. 
no I don't think that is a dupe.  134517 had to do with cache corruption but it
was caused by running different versions with the same profile.
*** Bug 195187 has been marked as a duplicate of this bug. ***
Keywords: qawanted
From Bug 195187:


Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b)
Gecko/20030210

I've changed some settings in the all.js:
pref("network.http.max-connections", 256);
pref("network.http.max-connections-per-server", 32);
pref("network.http.max-persistent-connections-per-server", 8);

I've never had problems with it in earlier Betas - but in 1.3b, sometimes the
images do not appear where they should. They swap place with other images on the
page.
I've noticed this problem several times on several pages.
The first thing I did, was to erase the whole cache, then reloaded the page -
useless: the images still swaped, but different.

But this problem does not last long - after browsing a little bit on other pages
the problem was gone.

HTTP-Pipelining (HTTP 1.1) was enabled. And there we are! I've just tested it
without HTTP-Pipelining and it worked as it should, then tested it again the
other way round and the bug occured again.

It is assured that it is a problem with HTTP-Pipelining.
Confirming comment #25
I have the same problem with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210

I can see this effect when browsing pages that contain lots of pictures
(pictures have the same width and height).
Sometimes the html page is not loaded by instead the binary code of a picture is
displayed.
It seems to work when pipelining is disabled.
*** Bug 196519 has been marked as a duplicate of this bug. ***
Okay my rather non-technical point of view on the whole problem is the if
pipelining is enabled as well as keep alive is enable the http response must be
completed and flushed before any new request over the existing connection is
made. Now how to implement this in the code is gonna be another matter I don't
really have the faintest knowledge about mozilla project and ain't gonna start
to download the CVS on me modem again ( I've done it before and as typical the
inital lot I download was broke LOL thankfully I hadn't wiped the cvs folder).

Mkay thanks for reading the useless stuff I just posted.
John - the whole point of pipelining is that things don't get "flushed" - the
browser sends a bunch of requests off at once, the server sends back all the
stuff, and then the browser sorts it out, which means you don't need to
synchronise between each file. what you're describing is "don't do pipelining"
:)  turning off pipelining is certainly a solution, and indeed it's off by
default, which is why this isn't a high priority bug. however, it'd be nice if
it worked better.

making summary more general.

this has 'qawanted'. I run into this quite often. the steps in bug 196519 are a
reasonably reliable way of reproducing it for me. what further QA would be useful?
Summary: Website caches constantly corrupted → Website content (images) mixed up (caches constantly corrupted) with pipelining
Blocks: 196835
*** Bug 197951 has been marked as a duplicate of this bug. ***
Confirmed on 1.3, with or without pipelining. Came with 1.3b, extremely annoying.
hmm.. bug 195746 was just fixed yesterday for moz 1.4 alpha.  there might be
some overlap here with that bug... though this bug has been on file for some time.
this bug has been on file for some time, but it goes quiet after June 2002 (and
I stopped experiencing these pipelining problems around then), until the new
dupes and comments that appeared after your changes earlier this year (when I
started experiencing problems again).

my guess would be that the original problems went away, and this bug has been
kept alive because of the problems that you've hopefully just fixed (thanks!)
with the patch in bug 195746.

I'd suggest marking this fixed (or dupe of the newer one), and then handling any
new reports in a shiny new bug... but up to you of course.
agreed =)

*** This bug has been marked as a duplicate of 195746 ***
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
haven't seen any problems like this since the fix went in. :)

verified.
Status: RESOLVED → VERIFIED
No longer blocks: profile-corrupt
You need to log in before you can comment on or make changes to this bug.