On Wed, Nov 30, 2011 at 3:53 PM, Bjarne <[email protected]> wrote: > 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.
yes > It doesn't seem like we handle "no-store" on requests > - do we want to do that? (Rfc2616 explicitly allows it.) Keep in mind that RFC 2616 often means proxy servers when it talks about caches. I don't think it makes any sense to let necko handle a Cache-Control request header, because this will be application generated, and the INHIBIT_CACHING header is a much easier way to specify that. Do you have any specific use case for this in mind? > nsIRequest.INHIBIT_PERSISTENT_CACHING: Entry is stored > in mem-cache and can be reused for subsequent requests, > including from view-source. indeed > 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? Nothing. We leave it alone. > - How should view-source (if relevant!) handle such > resources if there was no existing cached entry? Good question, I think right now we reload the page, and I think that seems most reasonable? That said, INHIBIT_CACHING is rarely used for HTML requests. > - How is this different from "Cache-Control: no-store" > (except for the view-source)? Should be mostly the same, I think. -christian > > 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 _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
