136210 - cannot view any https urls when memory cache size is set to 0

Status: VERIFIED FIXED

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

Description

[Ari Berger]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    .9.9

If I change my cache options to 0K available for memory cache, I cannot view 
any https pages.
(Note: if I set BOTH memory and disk cache to 0K, I CAN view the page ?!?)


Reproducible: Always
Steps to Reproduce:
1. Set memory cache size to 0K
2. View https://208.185.86.81/ari/byterange/byterange.txt
3.

Actual Results:  I don't see the page

Comment 1

[Matthias Versen [:Matti]]

-> PSM

Comment 2

[John Unruh]

Confirming.

Comment 3

[Kai Engert (:KaiE:)]

The trick for reproducing is indeed to have "memory cache => zero, disk cache =>
not zero". I see the problem, too.

I don't have an immediate idea how this could be a bug in PSM.
Will need to debug.

Gagan, do you have an idea what could cause this?

Note: We are using I/O layering to implement https.

Comment 4

[Gagan]

this seems bad. cc'ing gordon-- maybe we should have a minimum mem-cache size
that prevents these problems. 

Comment 5

[Kai Engert (:KaiE:)]

*** Bug 136380 has been marked as a duplicate of this bug. ***

Comment 6

[Kai Engert (:KaiE:)]

I suggest we make this nsbeta1+.
Nominating for release note.

Comment 7

[John Unruh]

Relnote: If you set the memory cache to 0, you should set the disk cache to 0 
also, or you will not be able to view https:// (secure) web sites.

Comment 8

[John Unruh]

*** Bug 139746 has been marked as a duplicate of this bug. ***

Comment 9

[John Unruh]

Several users have run into this bug, and the workaround is not obvious. Gordon, 
the crypto team is requesting your help on this one, since they don't have time 
for a proper fix. The bug is that if memory cache is set to 0, and disk cache is 
not set to 0, then the user cannot visit https sites.
We are hoping that you could change the cache preferences UI so that memory 
cache cannot be set to 0 if disk cache is also not set to 0.

Comment 10

[Gagan]

Hmmm.... Gordon is away on sabbatical. Darin might be able to take a look into this.

Comment 11

[Dan Yefimov]

*** Bug 147388 has been marked as a duplicate of this bug. ***

Comment 12

[Darin Fisher]

hmm... so it seems that the HTTP module isn't properly falling back on no
caching in this case.

reassigning to Networking:HTTP

Comment 13

[Darin Fisher]

ok, after some investigation the problem appears to be that the cache is not
enforcing storage policy when opening a cache entry.  given a memory cache only
cache session, it still gives out cache entries.  that is incorrect... it should
error out.  if it errored out then we would proceed without using the cache.

Comment 14

[Darin Fisher]

Attachment: v1 patch

this patch adds an additional check to nsCacheService::ActivateEntry to verify
that storage is available to satisfy the cache request.

Comment 15

[Patrick C. Beard]

Comment on attachment 85704 [details] [diff] [review]
v1 patch

r=beard

Comment 16

[rpotts (gone)]

Comment on attachment 85704 [details] [diff] [review]
v1 patch

sr=[e-mail]

Comment 17

[Darin Fisher]

fixed-on-trunk

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 85704 [details] [diff] [review]
v1 patch

please check into the 1.0.1 branch ASAP. once landed remove the 
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

Comment 19

[Tom Everingham]

set mem cache to 0 and was able to view page. 

verified trunk - 06/04/02 builds, winNT4, linux rh6, mac osX

Comment 20

[Darin Fisher]

marking FIXED per ADT convention (still not FIXED on the branch)

Comment 21

[Darin Fisher]

marking VERIFIED per comment #19

Comment 22

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this in asap, then add the "fixed1.0.1" keyword.

Comment 23

[Olav Vitters]

*** Bug 144916 has been marked as a duplicate of this bug. ***

Comment 24

[John Unruh]

*** Bug 110445 has been marked as a duplicate of this bug. ***

Comment 25

[Tom Everingham]

removing fixed 1.0.1 keyword