- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 17 Mar 2015 18:31:07 +1100
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: Erik Nygren <erik@nygren.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Think so… > On 17 Mar 2015, at 6:20 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > On 2015-03-17 06:42, Mark Nottingham wrote: >> I’m not hearing any pushback on this, so I’ve marked #16 as editor-ready, with this note: >> >> “”” >> Discussed on-list. Cache invalidation is to be scoped to a specific discovery mechanism; e.g., the alternatives you discover via the response header will be invalidated when you see a new response header, while those that were discovered via the frame will be invalidated only when a new frame is received. >> >> This means each mechanism needs to define its own exact invalidation semantics, and probably needs to be capable of carrying multiple alternatives. >> “”” >> >> Cheers, > > We have two mechanisms, and both can carry multiple alternatives, right? > > So what's left to do is to state the invalidation semantics? > > Best regards, Julian > -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 17 March 2015 07:31:36 UTC