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

RE: ID for Immutable

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Wed, 26 Oct 2016 23:50:12 +0000
To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <BN6PR03MB27085E0172450097B8B2733287AB0@BN6PR03MB2708.namprd03.prod.outlook.com>
I'm reading between the lines here, and would like to see your questions answered in the document.  However, I would interpret this as:  The cache should behave as if it *did* revalidate the resource and received a 304.

If the client sends an unconditional request, it should get a 200 and the stored payload.  If it sends a revalidation request, it should get a 304.  Whatever you would normally do when you revalidate your stored resource and find it still good.

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz] 
Sent: Wednesday, October 26, 2016 4:36 PM
To: ietf-http-wg@w3.org
Subject: Re: ID for Immutable

On 27/10/2016 10:02 a.m., Patrick McManus 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.
> 


This control seems like it will also be useful for proxy caches to prevent relaying the same revalidations from older clients that don't support the control.

However the draft does not mention any proxy handling.

* does it override must-revalidate etc on the stored response?
 - what about proxy-revalidate?

* does it override a client request max-age=0 and/or request no-cache?
 - the stated intention implies that it does.

* assuming immutable overrides those client reload signals; is the proxy supposed to deliver a 200, 304 or 4xx to clients sending max-age=0 ?

* how does immutable interact with the 'must not send on re-use' headers?
 - ie. no-cache="Set-Cookie", private="Set-Cookie" and similar cases ?

Amos

Received on Wednesday, 26 October 2016 23:50:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 26 October 2016 23:50:53 UTC