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

Re: ID for Immutable

From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 26 Oct 2016 20:18:31 -0400
Message-ID: <CAOdDvNq-o4=o25XmdGPNdcSX5teQa5Yn8090CGmi8jZVLtas_Q@mail.gmail.com>
To: Pete Wildsmith <pete@weargoggles.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Oct 26, 2016 at 7: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.
>
>
technically no.. immutable does not place any requirements on the client -
it remains an implicit MAY though there is no point in revalidating a fresh
response served with immutable.


> 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?
>

I think Ben's got this one - the idea is to disambiguate reloading for
corruption-fixing (e.g. no-cache) from reloading for updates.


>
> 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:19:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 October 2016 00:19:11 UTC