Closed
Bug 223000
Opened 21 years ago
Closed 21 years ago
HTTP “Cache-control: no-cache” header is ignored
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: bugs, Assigned: darin.moz)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Pages sent with HTTP “Cache-control: no-cache” header set still cache to disk in
Mozilla v1.0 through version 1.5. When a no-cache cache control header is
specified the browser is expected not to cache the page to disk. In Mozilla
these pages are cached to disk, which may be re-called using "back" button or
from disk with any text editor.
Reproducible: Always
Steps to Reproduce:
You will need to create a nocache.html and/or nocache.pl page on a test server
with the HTTP “Cache-control: no-cache” header set.
Test Steps:
1) Install default of any mozilla v1.0 through 1.5
2) visit http://[webserver]/nocache.html
3) visit http://[webserver]/nocache.pl
4) Unplug network cable
5) Visit about:cache
6) view details on each link (including the "cache-control: no-cache" header)
7) use back button to go to nocache.pl, verify it shows up
8) use back button to go to nocache.html, verify it shows up
9) Close and Open browser
10) visit about:cache, verify both are still listed
11) attempt to visit .html, allow it to timeout
12) attempt to visit .pl, allow it to timeout
13) visit about:cache, verify they are not listed anymore
14) view cache file on disk, "_CACHE_001_"
15) entire page and headers for .html and .pl files are in there and easily
viewable.
Actual Results:
All test steps were performed on versions of mozilla v1.0 - 1.5 on Win98, Win2k
and RH 9. In each case mozilla did indeed ignore the cache-control header,
keeping a copy of it in the memory and on disk. Closing and opening the browser
shows them still in the cache, however you cannot go directly to the pages.
Attempting to go directly to the page will remove it from the about:cache page
listing after it times out. Viewing the harddrive file will show it still
available however it can't be pulled up in the browser.
Expected Results:
Should conform to RFC 2616
(http://www.cis.ohio-state.edu/htbin/rfc/rfc2616.html) see 13.4 Response
Cacheability.
Also tested this on NS Communicator 4.79, 6 & 7 and IE 5, 5.5 & 6 none of which
cached pages when specified by a HTTP “Cache-control: no-cache” header.
Assignee | ||
Comment 1•21 years ago
|
||
>Pages sent with HTTP “Cache-control: no-cache” header set still cache to disk in
>Mozilla v1.0 through version 1.5. When a no-cache cache control header is
>specified the browser is expected not to cache the page to disk. In Mozilla
>these pages are cached to disk, which may be re-called using "back" button or
>from disk with any text editor.
this is desired behavior, and it does not violate RFC 2616. to get the behavior
you desire, you need to send 'cache-control: no-store'. no-cache only means
that we must validate the cached copy of the document before reusing it under
normal browsing circumstances. we are allowed to show the user a stale document
when they press the back button.
Mozilla puts no-cache content in its cache for the explicit purpose of ensuring
file->saveas, view->pagesource, and back/forward work as expected by our users.
this bug is INVALID per RFC 2616.
Group: security
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 2•21 years ago
|
||
To quote section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT
use the response to satisfy a subsequent request without successful revalidation
with the origin server.
This implies that it is valid to cache a no-cache document because it would be
impossible to revalidate a document that is not in the cache.
Section 13.1.1 Cache Correctness seems to imply that behavior is prohibited by a
no-cache directive:
If a stored response is not "fresh enough" by the most restrictive freshness
requirement of both the client and the origin server, in carefully considered
circumstances the cache MAY still return the response with the appropriate
Warning header (see section 13.1.5 and 14.46), unless such a response is
prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache"
cache-request-directive; see section 14.9).
![]() |
||
Comment 4•21 years ago
|
||
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 and in
particular the "History mechanisms and caches are different" part.
Oh great Mozilla we are believers. We lay on thy alter three published
references that support your position:
HTTP Essentials: Protocols for Secure, Scaleable Web Sites by Stephen A. Thomas,
ISBN: 0471398233 (see page 68)
HTTP: The Definitive Guide by David Gourley, Brian Totty, ISBN: 1565925092 (see
page 182)
HTTP Developer's Handbook by Chris Shiflett, ISBN: 0672324547 (see page 164)
You need to log in
before you can comment on or make changes to this bug.
Description
•