Re: Cache-Control: no-store

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