Re: Proposal for i23: no-store invalidation

Ping?

I'm still struggling to understand what you want here; see also Roy's  
comment on the issue in the tracker.

Are you talking about 304 responses, 200 responses, *any* response to  
a GET...?

Also may be worth to look at my recent proposal which may affect this  
tangentially;
   http://www.w3.org/mid/19AC8559-09F9-44AE-90C5-5BA95ECCC3AA@mnot.net

Cheers,


On 09/05/2008, at 3:54 PM, Mark Nottingham wrote:

>
> OK, I've created
>  http://www3.tools.ietf.org/wg/httpbis/trac/ticket/117
>
> Henrik, could you identify the changes that need to happen in the  
> drafts?
>
> Cheers,
>
>
> On 17/04/2008, at 6:28 PM, Henrik Nordstrom wrote:
>
>>
>> ons 2008-04-16 klockan 18:58 -0700 skrev Mark Nottingham:
>>
>>> Can you give some examples? 4xx to a GET shouldn't invalidate the
>>> cache, and a cache is allowed to return a cached response when
>>> encountering a 5xx unless must-revalidate is present.
>>
>> I am not talking about error responses. I am talking about this text
>> which currently is only specified for HEAD and not GET:
>>
>>  If the new field values
>>  indicate that the cached entity differs from the current entity (as
>>  would be indicated by a change in Content-Length, Content-MD5, ETag
>>  or Last-Modified), then the cache MUST treat the cache entry as
>>  stale.
>>
>> It's a equally good rule for GET as for HEAD, and having them aligned
>> would help getting rid of cornercases such as the i23 question.
>>
>>> In any case, I believe we can close this issue with no spec  
>>> change; we
>>> may change text regarding cache invalidation separately.
>>
>> Yes. i23 requires no change. This is a separate but quite related  
>> issue.
>>
>> Regards
>> Henrik
>>
>>
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 8 June 2009 10:58:09 UTC