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

Taking a careful read-through again, I think the cleanest thing to do is to
change the ALTSVC frame structure to allow multiple alternatives.  Note
that the current text reads for the header:

   When an Alt-Svc response header field is received from an origin, its
value
   invalidates and replaces all cached alternative services for that origin.

but does not define anything similar for the ALTSVC frame.  Aligning the
frame and the
header would allow this to apply to both.

If we're changing the frame structure, I think it would be better to fold
the port and host into a single field.  Different non-TCP protocols may
have different ways of defining ports that may not necessarily be 16 bits.
To align them well, it also seems like it would make sense to have
Ext-Param in the frame as well
(which can be some to-be-defined-in-the-future string with the same format
as ext-param in Alt-Svc header)

For example:

  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)                         |
 +---------------+---------------+-------------------------------+
 | Num-AltAuth(8)|
 +---------------+---------------+-------------------------------+
 | Proto-Len(8)  |        Protocol-ID (*)                        |
 +---------------+-----------------------------------------------+
 | AltAuth-Len(8)|        Alt-Auth (*)                         ...
 +---------------+-----------------------------------------------+
 | Origin-Len (8)|          Origin? (*)                        ...
 +---------------------------------------------------------------+
 |                        Ext-Param? (*)                       ...
 +---------------------------------------------------------------+

This would allow the same things to be expressed in the header and the
frame.

      Erik






On Tue, Aug 19, 2014 at 7:09 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 19 August 2014 15:09, Erik Nygren <erik@nygren.org> wrote:
> > With a set of options
> > it becomes much more clear when the client can start taking action
> > without needing to worry about thrashing.
>
> I think that I can concede that point.  It will make the ALTSVC frame
> uglier, but that's fine.
>
> > Additionally, how does a server remove/replace an ALTSVC record it set
> > previously without waiting for a TTL expiration?
>
> That's only a problem if you forget about one.
>