- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 17 Mar 2015 16:42:41 +1100
- To: Erik Nygren <erik@nygren.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
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, > On 20 Feb 2015, at 3:24 pm, Mark Nottingham <mnot@mnot.net> wrote: > > Reading the thread again -- AIUI the intent is for invalidation to be scoped to a single discovery mechanism (the frame, a header, whatever). > > If that's the case, the use cases below will work, because they both use different mechanisms. > > So, I'm OK with this. We will need to be *very* careful to scope the invalidations, however. > > Cheers, > > >> On 25 Aug 2014, at 10:30 am, Mark Nottingham <mnot@mnot.net> wrote: >> >> So, to be clear, you're suggesting that both the Alt-Svc header field and the ALTSVC frame type have the side effect of cache invalidation? >> >> Personally -- I'm not sure that's a good idea. >> >> For example, imagine a http:// service that a) wants to use Opp-Sec and b) the alternate wants to do some load balancing, etc. >> >> The http:// service sets an Alt-Svc header field with a very long lifetime, so that Opp-Sec is as sticky as possible. >> >> The alternate, OTOH, uses a fairly short lifetime for load balancing. >> >> With cache invalidation, the alternate doing load balancing is going to clear the cache of the Opp-Sec hint, thereby forcing the client to go back to the http:// origin once the (short lifetime) load balancing policy expires. >> >> Without invalidation, it'd fall back to the original Opp-Sec alternative. >> >> Likewise for the SNI segmentation use case. >> >> Regards, >> >> >> On 24 Aug 2014, at 11:30 am, Erik Nygren <erik@nygren.org> wrote: >> >>> On Fri, Aug 22, 2014 at 7:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote: >>> On 22 August 2014 14:53, Erik Nygren <erik@nygren.org> wrote: >>>> but does not define anything similar for the ALTSVC frame. Aligning the >>>> frame and the >>>> header would allow this to apply to both. >>> >>> I think that we would want to move the Origin field up to the header >>> with Max-Age. Logically, you store alternatives for different origins >>> separately, so requiring different frames makes sense there. It also >>> removes any potential for duplication. >>> >>> Also 8 bits of length is not sufficient for an HTTP origin if the name >>> is maximum size. I'd assume that the same applies to authority. >>> >>> >>> Agreed on both counts. What about this, then: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Max-Age (32) | >>> +---------------+---------------+-------------------------------+ >>> | Origin-Len (16) | Origin? (*) ... >>> +---------------------------------------------------------------+ >>> |Num-Alt-Auth(8)| >>> +---------------+---------------+-------------------------------+ >>> | Proto-Len(8) | Protocol-ID (*) | >>> +---------------+-----------------------------------------------+ >>> | Alt-Auth-Len (16) | Alt-Auth (*) ... >>> +---------------+-----------------------------------------------+ >>> | Ext-Param? (*) ... >>> +---------------------------------------------------------------+ >>> >>> where Origin-Len=0 would be used in the case where this was part of a Stream != 0 >>> and Num-Alt-Auth>=1. The {Proto-Len, Protocol-ID, Alt-Auth-Len, Alt-Auth} would be >>> repeated Num-Alt-Auth times. Alt-Auth is a string such as "server.example.com:443" >>> >>> >>> >>> >>> >>> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 17 March 2015 05:43:11 UTC