On 9 July 2012 16:29, sebb <[email protected]> wrote: > 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.
This has now been implemented. >> 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.
