Closed Bug 223000 Opened 21 years ago Closed 21 years ago

HTTP “Cache-control: no-cache” header is ignored

Categories

(Core :: Networking: HTTP, defect)

x86
Windows 2000
defect
Not set
normal

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.
>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
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).
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.