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:36:59 UTC