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". Roy ultimately would be able to answer this? Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
