- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Sun, 17 Oct 2010 18:31:31 -0600
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > > Right, but that's largely orthogonal to the question below; whether > no-store in a request implies that a previously stored response needs > to be invalidated. > Whoops, I made the same mistake in my response. > > >>> If Squid does not purge, the next regular request will get the > >>> same cached response as the no-store request got, kind of > >>> violating the "MUST NOT store any response to it" no-store > >>> requirement. > I don't think it violates anything -- no-store says nothing about not caching *previous* responses, only the current response. The important thing is that no other caches between the user-agent and the responding cache, or the user-agent cache, stores the current response. If I want a response from the origin server, not a cache, I'd combine no-store with max-age=0. If I want to invalidate, I'd combine no-store with must-revalidate, basically erasing previously-cached responses. > > My inclination is to clarify "any response to it" so that a cache can > use the same cached response to serve multiple requests with no-store > in them (or not). > So I give this an on-second-thought +1, rather sheepishly... -Eric
Received on Monday, 18 October 2010 00:32:07 UTC