W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: ID for Immutable

From: Pete Wildsmith <pete@weargoggles.co.uk>
Date: Thu, 27 Oct 2016 00:57:06 +0100
To: ietf-http-wg@w3.org
Message-Id: <42BA6A75-AE2D-4C5E-A879-731D18EBB67B@weargoggles.co.uk>

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.

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? 


> On 26 Oct 2016, at 22:02, Patrick McManus <pmcmanus@mozilla.com> wrote:
> [as individual]
> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 26 October 2016 23:57:44 UTC