Closed Bug 72519 Opened 24 years ago Closed 9 years ago

support for cacheTokens must be implemented


(Core :: Networking: Cache, defect)

Not set





(Reporter: gordon, Unassigned)


(Blocks 1 open bug)


(Keywords: arch, Whiteboard: [cache])

This bug is really for clients of cache clients.

A cacheToken is simply an nsISupports with an nsICacheEntryDescriptor wrapped 
inside. It may even be an nsICacheEntryDescriptor that is handed out as an 

As long as the cacheToken is held, the underlying cache entry will not be 
evicted, and can be "reopened" using the token, even if the entry has been doomed 
(and therefore not discoverable by the normal key search).

This mechanism should be used to implement printing, save as, and view source.
Whiteboard: [cache]
Target Milestone: --- → mozilla0.9
Priority: -- → P2
Keywords: arch
Blocks: 68705
Blocks: 40867
Darin, I'm giving this to you so you can close it when you've implemented 
GetCacheToken() in http.
Assignee: gordon → darin
GetCacheToken() is implemented, but SetCacheToken() is not.  We currently do
not have any consumers of this, so I'm pushing back the milestone to Future.
Target Milestone: mozilla0.9 → Future
No longer blocks: 40867
Shouldn't printing be WYSIWYG and therefor use the current DOM rather then the 
original file? The two dosn't neccesarily produce the same result on for 
example dynamic pages and form elements.
What's the status on this?  I believe view-source is now using an interface
which is supposed to do the same thing.  (see bug 408767)  Meanwhile, save-as is
using a completely different workaround.  So I think you have consumers.

Could somebody with a deep understanding of the cache see if view-source is
doing the 'right thing', and if not, how hard it will be to make it do so?
erp, that should be bug 40867.  Dunno how that extra 7 got in there.
Don't also forget the "Send Page" (where it is especially embarassing if it
turns out you've sent something quite different from what you though you were
nope, view-source, etc. do not currently depend on cache tokens.  they use soft
references to cache entries, which allow the cache to free old entries in order
to make room for more recently visited content.  a cache token could be used to
hold a hard reference to a cache entry, causing it to never go away. 
view-source, etc. may one day make use of cache tokens, but for the moment, it
is not part of the design.  with a default disk cache size of 50 megabytes, we
think this design should be sufficient 99% of the time.  if you feel otherwise,
and would like to discuss the design of view-source, etc. then please take the
discussion to a news group, thx!
They don't currently depend on cache tokens *because* cache tokens aren't
implemented!  What, you want the consumers to break the build before you
consider this useful?

I'm going to try to fix this bug, but I need a hint: what file is GetCacheToken
defined in?
of course this bug blocks using cache tokens for view-source, etc.  but there
currently isn't any plan AFAIK to implement view-source, etc. using cache tokens.

[GS]etCacheToken for HTTP content are implemented in nsHttpChannel.cpp
Clearly you never read the enormous discussion in bug #40867.  The consensus
reached way-back-when seemed to be that cache tokens should be used for view-source.

However, there's a deeper problem than this bug, in that the cache doesn't
really allow proper implementation of cache tokens right now, since cache
entries can be 'overwritten' rather than being replaced.  *sigh*
i'm well aware of the fact that there is a proposed solution to implement
view-source using cache tokens (in fact it was one of the design reasons behind
exposing cache tokens on nsICachingChannel), but AFAIK there is no consensus
that this proposal is the right thing for mozilla, especially not amongst the
maintainers of the relevant code modules.

if we decide that cache entries need to be pinned in the cache for the purposes
of view-source, etc. then we'll need to fix this bug.  the work required to fix
this bug is very small, but until we're ready for it, i'd rather we focus our
efforts on the vast number of much more critical bugs ;-)
What about implementing IE's 'Offline Web pages' using this technology?
Permanently pinning all files in the cache which belong to a selected bookmark?
Should be easy.

Currently, I think there is no way to ensure specific pages are always kept in
the case - therefore I can't rely on pages shown in the History to be accessible
any time.
-> default owner
Assignee: darin → nobody
QA Contact: gordon → networking.cache
Target Milestone: Future → ---
*** Bug 262350 has been marked as a duplicate of this bug. ***
bug 262350 has a partial patch
Assignee: nobody → cbiesinger
Blocks: 115174, 182712
Priority: P2 → --
Darin Fisher: "if we decide that cache entries need to be pinned in the cache for the purposes of view-source, etc. then we'll need to fix this bug.  the work required to fix this bug is very small, but until we're ready for it, i'd rather we focus our efforts on the vast number of much more critical bugs ;-)"

Not pinning the currently open files is highly critical: It prevents people from printing or saving receipts from online credit card purchases; It prevents people on dial-up from saving images and other files that they spent hours downloading; It prevents web developers from viewing the actual source of the page they are looking at while they debug their dynamic web sites; many other harmful data loss issues.

Pinning all open pages (and preventing them being overwritten by any other loading of the same URL in a different tab/window) should be the default behaviour.
Bug 288462 provides the full summary of all related issues, complete with RFC violations.  Should be linked to this one.
Assignee: cbiesinger → nobody
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.