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

Re: ID for Immutable

From: Ben Maurer <ben.maurer@gmail.com>
Date: Wed, 26 Oct 2016 17:08:40 -0700
Message-ID: <CABgOVaLGvsW4LP8d2Y4w4y1Te6N+4fDKbOC8HYea8NmzJ5TQRw@mail.gmail.com>
To: Pete Wildsmith <pete@weargoggles.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
This extension is only for use by sites which actually ensure that they do
not change their resources. If a developer wishes to have the reload button
refresh subresources, they should not use immutable.

Keep in mind that all browsers have an escape hatch which lets the user do
a hard refresh. This does not invalidate any resources and requests them
from scratch.

On Wed, Oct 26, 2016 at 4:57 PM, Pete Wildsmith <pete@weargoggles.co.uk>
wrote:

> 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 Thursday, 27 October 2016 00:09:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 October 2016 00:09:16 UTC