On Wed, Mar 13, 2013 at 6:20 PM, Graham Leggett <minf...@sharp.fm> wrote: > On 11 Mar 2013, at 12:50 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > >>> The way I read the spec, "the specified field-name(s) MUST NOT be sent in >>> the response to a subsequent request without successful revalidation with >>> the origin server". What this means is that if the specified field names >>> are found to be present in the cached response, then the origin server >>> needs to be given the opportunity to update these fields through a >>> conditional request. In the current cache code, we return 0 meaning "this >>> is stale, revalidate", and a conditional request is sent to the origin. We >>> hope the origin sends "304 Not Modified", with updated headers >>> corresponding to the fields. >> >> Ok, I see your point, and this is surely the right reading of the rfc, >> but there is necessarily a difference between no-cache and >> no-cache="<header(s)>", particularly with the handling of that (stale) >> header(s). >> >> For what I understand now, if the origin does not send (one of) the >> header(s) in its 304 response, the stale header(s) "MUST NOT" be >> served. > > I don't read it that way from the spec, I think it all comes down to the > phrase "without successful revalidation with the origin server". I read it as > "without successful revalidation [of the whole request] with the origin > server". In other words, the origin server sent the original header, if the > origin server doesn't update the header in the 304 response then it means > "I've had my opportunity to revalidate the entity, current cached value is > fine, send it".
How would the origin invalidate a Set-Cookie, with an empty one ? Regards, Yann.
