On 9 July 2012 06:45, Philippe Mouawad <[email protected]> wrote: > Hello Sebb, > I understand no-store differently, > For me it means do not store on disk but you CAN store it on volatile > storage, so in our case, we should store it in cache.
Possibly. > For me current implémentation is correct Not sure we are correct now. We no longer store responses at all for "no-cache". This means they cannot be revalidated. AIUI, if the revalidate says that the no-cache response is still up to date, a browser can use it. However the browser must not use the cached entry without checking first; in other words, it should ignore the expires date. So I think the check for no-cache should be done as part of the useExpires conditional (as originally proposed by Philippe, and wrongly rejected by me). If no-cache is present, store null in the expires field; this will stop the entry from being directly returned. > as we say That we don't interpret > other attributes for example must-revalidate. That was for simplicity in the initial implementation. We could do so later. > Regards > Philippe > > On Monday, July 9, 2012, sebb wrote: > >> I misunderstood how the "no-cache" attribute is supposed to work. >> >> According to >> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 >> >> the browser CAN store responses marked as "no-cache", however the >> browser MUST revalidate the response. >> Without the attribute, then the entry can be re-used without >> revalidation provided that it has not expired. >> >> The "no-store" attribute is the one that is intended to prevent >> storage of the response in cache. >> > > > -- > Cordialement. > Philippe Mouawad.
