Closed Bug 184304 Opened 22 years ago Closed 18 years ago

When memory cache is disabled, no-store pages are not displayed at all

Categories

(Core :: Networking: HTTP, defect, P5)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8.1beta2

People

(Reporter: taviso, Assigned: mozilla)

References

(
URL
)

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

Patch following comment 19
(deleted), patch
Biesinger
: review+
darin.moz
: superreview+
mtschrep
: approval1.8.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

im not an expert in mozilla or HTTP, ive just reviewed the documents in regards
to  a characteristic in moz that i think should be reviewed...

if mozilla's memory-cache is disabled by setting its size to 0 KB, it responds
to the no-store cache-response-directive by not displaying the page at all, i
assume this means that as mozilla is unable to keep the page in volatile storage
it decides to simply not display the page at all. No error or status indication
is given, the statubar simply displays "Done.".

i think this is wrong, and not what was intended in rfc2616, and also not what a
user would expect, a user might believe that there was an error in mozilla as no
indication of what has happened is displayed, eg [ bug 182684 ].

rfc2616 says "'MUST NOT store' in this context means that the cache MUST NOT
intentionally store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile storage as promptly
as possible after forwarding it." so mozillas behaviour is understandable, but
surely having a user disable the memory cache means that mozilla isnt
intentionally storing the data on a non-volatile medium (obviously the disk
cache in this case), but has no other choice but to. If mozilla then removes it
from the disk cache after use then i believe the directive has been observed. 

even if people with more experience than me disagree, surely an option to ignore
no-store in a dialog when disabling memory cache or at least an error message
would be nicer behaviour?


Reproducible: Always

Steps to Reproduce:
1. Disable memory cache by setting its size to 0KB
2. Fetch a webpage sent with the no-store cache-response-directive

examples:

http://www.cdbaby.com/
http://appdb.codeweavers.com/

3. mozilla wont display it.

Actual Results:  
Mozilla refuses to display the page as it has no volatile store to write to.

Expected Results:  
Displayed the page, then removed it from cache or display an error. SSL pages
still function.

rfc2616 relevant section 

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2

old cachefaq

http://www.mozilla.org/docs/netlib/cachefaq.html
The real bug is that we're not rendering it.  We should not require the cache to
render a page.
Confirmed - Day old trunk LINUX.

hmm... odd... by design, necko does not depend on the cache in order to download
stuff.  investigating...
the problem is here:

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#704

we should just close the cache entry if an error occurs while trying to
initialize it instead of bailing.  i suspect this configuration has simply never
been tested.  (by the way, running w/ a zero sized memory cache is not a good idea.)
Severity: normal → trivial
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → mozilla1.4alpha
*** Bug 184261 has been marked as a duplicate of this bug. ***
Confirming for Mozilla 1.1 and later on WinNT4. However, I have a memory cache
of 4MB, not 0 (disk cache 80MB). Two more example pages are
http://www.dresden-stadtplan.de/ and http://www.dvbag.de/inhaf/default.asp .
If someone could confirm this behaviour with a memory cache > 0, I'd recommend
to change the severity to 'major'. (Honestly, this makes me going mad.)

2 calocybe@web.de: try to see if 'user_pref("browser.cache.memory.enable",
false);' does exists in your prefs.js. To know more -- follow the previous link
about the duplicate of this bug, or this one
http://bugzilla.mozilla.org/show_bug.cgi?id=184261#c5
You are right, the mem cache was disabled by this line. Can anybody tell me how
this line came in there? I'm pretty sure I didn't write it. (And as I first
noticed this with Mozilla 1.1 I probably didn't do this in the debug prefs.)

Have set it to true now and the pages in question load fine, so please consider
my previous posting trash.

You may have disabled memory/disk cache in pref panel (Edit | Pref | Debug |
Networking).

Even with memory cache disabled, I couldn't duplicate this bug. i.e
http://www.cdbaby.com/ and http://appdb.codeweavers.com/ loads fine with all the
images.

Anyone else still seeing this issue? Thanks!
so perhaps this issue has somehow been fixed since moz 1.2.1?

suresh: what version did you test?
Target Milestone: mozilla1.4alpha → Future
darin: I tested using the latest trunk builds when I last tested (on 3/4/03).
Have tested version 1.3 (win32) with line
'user_pref("browser.cache.memory.enable", false);' in prefs.js, and the bug
still exists. 
*** Bug 180447 has been marked as a duplicate of this bug. ***
*** Bug 175478 has been marked as a duplicate of this bug. ***
*** Bug 227083 has been marked as a duplicate of this bug. ***
*** Bug 234757 has been marked as a duplicate of this bug. ***
Dupes have OS as Windows XP and All -> All.
OS: Linux → All
Why the Severity is set to Trivial? This is no trivial, since by mistake (my
case, see one of the duplicates (Bug 184261#c5); and not only my duplicate, most
duplicates of this bug do not know what the problem is with) user cannot see
some major web-sites anymore... Please, consider to mark it Major, and set the
higher priority. 

Has anyone tested this on a different platform? I bet it is not PC-specific...
Marking Hardware: All. 

This behaviour should be documented in the release notes (CC'ing asa and adding
'relnote' keyword).
Keywords: relnote
Hardware: PC → All
1) Setting browser.cache.memory.capacity to zero is identical to setting
browser.cache.memory.enable to false.
(nsCacheProfilePrefObserver::MemoryCacheEnabled returns PR_FALSE if the capacity
is zero otherwise it returns the enabled status.)
2) nsHttpChannel::InitCacheEntry will fail because it calls
mCacheEntry->SetStoragePolicy(nsICache::STORE_IN_MEMORY) which will fail because
the memory cache is disabled.

As mentioned in comment 4:
3) nsHttpChannel::ProcessNormal will fail because it calls
nsHttpChannel::InitCacheEntry.
I tried Darin's proposal to disable the cache and it seems that this works fine.
I replaced the marked line in
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp&rev=1.191&mark=762#743
with
    if (NS_FAILED(rv)) 
        CloseCacheEntry(rv);


We don't even have primary UI to set memory cache that I know of. If you're
hacking your prefs file with a text editor or about:config, you're on your own.
This is not release note worthy and might even be worth wontfixing.
Keywords: relnote
I see this is a long standing bug, which has been assigned low priority. 

I would like to add my 2 cents, that disabling the memory cache for me has
enhanced performance significantly. 

You see, I regularly run mathematical simulations which consume >1GB of RAM. 
Under these circumstances other processes quickly get swapped out to the page
file, which I presume includes mozilla and its "in memory" cache. (or is the
memory cache somehow flagged as non-swappable memory?)  

The delays when using Mozilla after it has "swapped out" are reduced with the
memory cache disabled. (Note: a purely subjective comparison) With the memory
cache disabled, mozilla consumes much less Virtual Memory (usually around 20MB,
as opposed to 30-60MB), which probably helps a lot too.

However, I have quickly run into these problems where a page doesn't display. My
example is any page generated by 'Tiki': sourceforge.net/projects/tikiwiki/

Could the meaning of the memory-cache preference could be changed to "prefer
disk", so that when the storage policy dictates the page be held in memory, it
can be. The memory can be released as soon as such a page is closed. 
Interestingly, if you set both types of cache off:
  browser.cache.disk.enable = false
  browser.cache.memory.enable = false

Then the various "problem pages" no longer have any problems!  So this bug must
only occur when disk=true and memory=false. (In Mozilla v1.8 beta 1)
(In reply to comment #20)
> We don't even have primary UI to set memory cache that I know of. If you're
> hacking your prefs file with a text editor or about:config, you're on your 
own.

You're right about that, I was using galeon when I reported this bug, which did 
have a UI to set the cache size (I don't know if it still does), I didnt check 
if mozilla had a way to set it.
*** Bug 236682 has been marked as a duplicate of this bug. ***
Summary: no-store cache-response-directive possibly incomplete implementation → When memory cache is disabled, no-store pages are not displayed at all
I would like to be able to run Firefox with no memory cache, in order to avoid
problems introduced by bug 284716
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Flags: blocking1.8b2?
Flags: blocking1.8b2-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
> I would like to be able to run Firefox with no memory cache

that's a really bad idea, fwiw. stuff like file|save page as and view source
will probably always retransmit the data, at least for https:// urls.
this bug is still present in rv1.8 gecko/20051111 (firefox 1.5).
*** Bug 287501 has been marked as a duplicate of this bug. ***
*** Bug 309351 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2?
*** Bug 321190 has been marked as a duplicate of this bug. ***
This doesn't seem like a blocker, but the Gecko folks can decide.
Flags: blocking-firefox2? → blocking1.8.1?
I don't think this should block the FF 2 release.  Disabling the memory cache is an unsupported mode of operation.  You can set its size to something small, but it shouldn't be set to zero size.

Target milestone is future for a reason.  Patches welcome, but I don't plan on fixing this anytime soon.
Keywords: helpwanted
*** Bug 323902 has been marked as a duplicate of this bug. ***
(In reply to comment #32)
> I don't think this should block the FF 2 release.  Disabling the memory cache
> is an unsupported mode of operation.  You can set its size to something small,
> but it shouldn't be set to zero size.
> 
> Target milestone is future for a reason.  Patches welcome, but I don't plan on
> fixing this anytime soon.
> 

How the size of memory cache can be set? I do not see the corresponding parameter.
*** Bug 327489 has been marked as a duplicate of this bug. ***
(In reply to comment #21)
> I see this is a long standing bug, which has been assigned low priority. 
> 
> I would like to add my 2 cents, that disabling the memory cache for me has
> enhanced performance significantly. 

Totally agree with this comment.

Since FF1.5 release I was suffering huge memory problems, swapping etc. and tried everything I could find about tweaking this poor bastard. Then I found a solution - browser.cache.memory.enable = false. I was happy for some time but I was wrong because some pages did not open at all. And my luck was gone again.

IMHO until most of the memory problems are solved this setting would be the solution for users who has swapping problems (every other user?). At least I have not seen any other working solution like this one.
Agree with Darin in comment 32, not a blocker.
Flags: blocking1.8.1? → blocking1.8.1-
As far as I can see, this bug is fixed at least for Firefox 1.5.0.2 build 20060419. May be it's time to mark this bug as fixed?
Not fixed in trunk nightly. Perhaps you're testing wrong?
What Firefox branch did you test?  1.5, 2.0 or 3.0?
bug still exists in 1.5.0.3.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
This bug is definitely still present in FF 1.5.0.4. I spent a few hours hunting through my website source for an obscure bug affecting some FF users and it turned out to be this. The workaround was simple - simply take "no-store" out of my cache-control headers, but I think it's high time that this bug be ratcheted up the priority list. In the course of researching this issue I found a number of "tips & tricks" sites that recommend disabling the memory cache as a matter of course. There are also numerous sites that use "no-store".

I don't understand what's the problem with fixing this. People have gone to the trouble of identifying the relevant section of code and fixed it. Surely it's just a matter of pushing it into the next release cycle???? Why hasn't it been done already??? Seems like a no-brainer to me.
*** Bug 250218 has been marked as a duplicate of this bug. ***
Assignee: darin → nobody
Status: ASSIGNED → NEW
Attached patch Patch following comment 19 (deleted) — — Splinter Review 
There is probably a reason why Daniel did not make his fix from comment 19 into a patch to get reviews, but I am trying it anyway. It still seems to fix it for me (tested with trunk on OS/2) without any side-effects that I could see.
Attachment #227286 - Flags: superreview?(darin)
Attachment #227286 - Flags: review?(cbiesinger)
Attachment #227286 - Flags: superreview?(darin) → superreview+
Comment on attachment 227286 [details] [diff] [review]
Patch following comment 19

could you add -p to your diff options for future patches? thanks!

imo it would also be good to get this fixed for the 1.8.0 and 1.8 branches
Attachment #227286 - Flags: review?(cbiesinger) → review+
-> peter
Assignee: nobody → mozilla
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 227286 [details] [diff] [review]
Patch following comment 19

requesting branch approval. this should be a pretty safe patch, it just makes failure to initialize the cache entry not fatal.
Attachment #227286 - Flags: approval1.8.1?
OK, putting this on the FF2 beta2 list.
Flags: blocking1.8.1- → blocking1.8.1+
Target Milestone: Future → mozilla1.8.1beta2
Attachment #227286 - Flags: approval1.8.1? → approval1.8.1+
Whiteboard: [checkin needed (1.8 branch)]
Peter, should I check this in on the branch?
Gavin, yes, thanks that would be great.
I checked this in on MOZILLA_1_8_BRANCH since I was also doing some other checkins

Checking in netwerk/protocol/http/src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v  <--  nsHttpChannel.cpp
new revision: 1.256.2.19; previous revision: 1.256.2.18
done
Keywords: helpwanted → fixed1.8.1
Whiteboard: [checkin needed (1.8 branch)]
(I also checked in the bustage fix that was necessary due to the different CloseCacheEntry signature on branch)
*** Bug 353471 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: