Re: ID for Immutable

Patrick,

the relevant section of RFC7234 suggests that conditional requests before the end of the freshness lifetime are made at the discretion of the cache.

> When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.
https://tools.ietf.org/html/rfc7234#section-4.2

My understanding of your extension is that for responses with the extension, the implicit MAY in the quoted sentence would become a SHOULD or MUST.

This seems to conflict with user-agents’ reload behaviour. If all resources that are not expected to change during the lifetime of the resource begin using this extension, will it not become necessary for ‘reload’ to invoke a process which ignores the extension for the same reason that ‘max-age=0’ is now sent? 

Pete

> On 26 Oct 2016, at 22:02, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> [as individual]
> 
> FYI
> 
> A new version of I-D, draft-mcmanus-immutable-00.txt
> has been successfully submitted by Patrick McManus and posted to the
> IETF repository.
> 
> Name:           draft-mcmanus-immutable
> Revision:       00
> Title:          HTTP Immutable Responses
> Document date:  2016-10-26
> Group:          Individual Submission
> Pages:          4
> URL:            https://www.ietf.org/internet-drafts/draft-mcmanus-immutable-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mcmanus-immutable/
> Htmlized:       https://tools.ietf.org/html/draft-mcmanus-immutable-00
> 
> 
> Abstract:
>    The immutable HTTP response Cache-Control extension allows servers to
>    identify resources that will not be updated during their freshness
>    lifetime.  This assures that a client never needs to revalidate a
>    cached fresh resource to be certain it has not been modified.
>

Received on Wednesday, 26 October 2016 23:57:41 UTC