Re: Alt-Svc alternative cache invalidation (ext#16)

Ah, of course.  Having different data models between the header and the
frame
seems like it will be unfortunate and lead to more complicated
implementations.
If we're going to allow multiple Alt-Svc header targets, it seems like we'd
want
something similar for the frame, especially if we have full set replacement
semantics which seems potentially easier to reason about.

Could we alter the ALTSVC frame to allow for multiple targets within
the frame?  Or have a flag of "more ALTSVC follows" to allow a series
of the frames in-sequence for the same origin?  Either would bring
the two back in alignment.  The latter seems more annoying from
a state machine perspective.

       Erik



On Mon, Aug 18, 2014 at 1:42 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 18 August 2014 10:37, Erik Nygren <erik@nygren.org> wrote:
> > Would it make more sense for (origin) to be the key with a set of
> (service
> > protocol, service endpoint) tuples being the value?  This allows a reset
> or
> > correction (or removal?) by publishing a new set of [(service protcol,
> > service endpoint), ...] values.
>
> The problem is that there are two different ways to update the set:
>
> * The Alt-Svc header field bears multiple values and could be used in
> the fashion you describe.
>
> * The ALTSVC frame type bears just a single value.
>
> The latter is the problem here.
>