Ok - I'll sum up my understanding of these issues
but grab the opportunity to raise a few questions:
"Cache-Control: no-store" on a response: Entry is
stored in mem-cache in order to be used by view-
source, but never reused for subsequent requests.
It doesn't seem like we handle "no-store" on requests
- do we want to do that? (Rfc2616 explicitly allows it.)
nsIRequest.INHIBIT_PERSISTENT_CACHING: Entry is stored
in mem-cache and can be reused for subsequent requests,
including from view-source.
nsIRequest.INHIBIT_CACHING: Entry is not stored anywhere.
However, if an existing entry is found in the cache it can
be reused to satisfy this request.
- What do we do with an existing cached request after
reading it?
- How should view-source (if relevant!) handle such
resources if there was no existing cached entry?
- How is this different from "Cache-Control: no-store"
(except for the view-source)?
Regards,
- Bjarne
On 11/30/2011 11:15 PM, Christian Biesinger wrote:
On Wed, Nov 30, 2011 at 1:41 PM, Bjarne<[email protected]> wrote:
[ Forwarded from a mail-thread on necko-devs.
The topic is how to understand the http-header
"Cache-Control: no-store". ]
So, if I understand you both correctly, the
expected behaviour is to not store such responses
at all, not even in the mem-cache?
We have to store it in the memory cache so that view-source works
correctly. We just never reuse it.
What about our nsIRequest.INHIBIT_PERSISTENT_CACHING
flag? Should we allow responses to such requests to
be stored in mem-cache?
Yes. That's how this flag is documented to work, and how would it
differ from INHIBIT_CACHING otherwise?
-christian
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
