47401 - Test Suite for Cache

Status: RESOLVED WORKSFORME

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

Description

[Gagan]

We badly need a good test suite for testing the cache. We should add the list of
specific items that we need to be tested but a good starting point would be the
test suite used for 4.* browsers. 

tever you should also consider getting this out on to mozilla.org to allow
people on the net to help us.

Comment 1

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 2

[Blake Ross]

Removing [nsbeta3+] for reevaluation.  Why does the creation of a test suite 
need to be nsbeta3+?

Comment 3

[bht237]

Suggestion 1 from a problem that has never been resolved in Netscape 4:

- Clear cache
- Open Large size URL over a slow connection e.g. http://www.w3.org/TR/REC-CSS1
- stop transfer before I/O is completed.
- Investigate cache content carefully. Even with the highest level of cache
  setting, an interrupted page should NEVER be cached.

Below is a report of what Netscape 4 does in such a scenario:

"Tranfer Interrupted" corrupted pages saved in disk cache

____
Scope

The bug affects advanced internet commerce sites whose content is browser cachable
(cacheable is the default setting on current internet web servers).

_____________________________
What causes the bug to "bite"

If during the loading of a HTML file, data transfer is interrupted by one of the
following events:

1) Network unavailability e.g. modem disconnect
2) User clicks browser "Stop" button
3) User presses [Esc] key or equivalent (on MS Windows keyboards, this key is
very exposed and might get pressed accidentally)

_________________
What the bug does

1) The incompletely loaded HTML file is modified by the Netscape browser as follows:
   - A String <HR><H3>Transfer interrupted!</H3> is inserted on a new line at
the point
     where transfer was interrupted. This is a string that most Netscape users are
     probably quite familiar with. However, this HTML string is also inserted in
     JavaScript code, which causes immediate JavaScript errors.
   - The remainder of the document is sometimes appended where transfer could resume
     and subsequently, the complete page could be loaded.
     In this case, the corruption could have been avoided by not inserting the
string.
2) The modified (corrupted) page is stored in the Netscape user's cache. This is
a fundamental problem, more serious than 1)
3) On subsequent requests for the same page, the corrupted page is fetched from
the cache and causes the same errors.
   At this point, depending on the nature of the web application (JavaScript,
frames etc), 
   a total meltdown of the web based application occurs because the user has no
way to
   recover from the error even if the network connection is fully established.
4) In a frames based application, a frame reload (Windows: right click on frame,
select 
   "Reload Frame") fetches the corrupted page from the cache and DOES NOT reload
from
   the network.

________
Symptoms
The symptoms range from the display of the "Transfer interrupted!" message to
far more
complicated scenarios.
Symptoms can be very hard to diagnose in case of JavaScript errors because the
Netscape
default setting is to not display any JavaScript errors.

______
Remedy

1) Navigate away from the site, clear both disk and memory cache or:
2) With default cache settings: Close all Navigator windows.


_____________
Documentation


_________________________
How to reproduce this bug

1) Review your cache settings (Menu|Edit|Preferences|Advanced|Cache|check "Once
per Session"
1) Navigate to large page hosted on server  e.g. http://www.w3.org/TR/REC-CSS1
(local disk files are not affected)
2) Verify that this page is in the cache: Menu|View|Page Info.
   In the bottom frame, you should see: "Source:  Currently in disk cache"
3) Navigate away from the page
4) Clear your disk caches: Menu|Edit|Preferences|Advanced|Cache
   Click button "Clear Memory Cache"
   Click button "Clear Disk Cache"
   Click OK
5) Navigate back to the page and while it is loading, press the [Esc] key or click
   "Stop".
6) You should see the error now. If not, then repeat steps 3) to 5).
7) Navigate away from the page again.
8) Navigate back to the page. The error is still the same; the corrupted page
was fetched
   from the cache.

Comment 4

[Gagan]

wow... there already is a bug for this! Tever any progress on this?

Comment 5

[Tom Everingham]

Gagan, I have some of the 4.x cache tests revised and a list of tests to create  
that I am working on.   I will post a link to these sometime this week.   

Comment 6

[chris hofmann]

unsetting milestone.  lets retarget when we get things up and running 
and get some test results.

Comment 7

[Ulrich Grassberger]

I want to throw in another issue: Shouldn´t the client for every display of a
certain page ask the server if there is an updated version of the document, in
other words retrieve the HTTP header? One should also have a look at what RFC
documents say about the expires: variable. 

Furthermore I experienced a problem when a server-side redirect (301 or 302) is
established inbetween two clicks on the same link; Mozilla will not reflect the
changes. 

The fact that Mozilla provides four alternatives for cache behaviour in a rough
EXOR ("radio button") manner makes clear that there is still much to do.

Comment 8

[Patrick McManus [:mcmanus]]

there are tests forthe cache