Re: ext#7 / ext#8: multiple alt-svc

On 3 July 2014 15:02, Kinkie <gkinkie@gmail.com> wrote:

> The selection algorithm can then be specified pretty simply: clients
> SHOULD choose randomly one alternate server but it MUST be among the pool
> having the highest-priority value.
>

If the client MUST choose from the highest priority pool, why would the
server ever bother sending those with lower values? Unless you're
suggesting the server-supplied q-values are combined with some client-side
preference metric to provide the final priority (a la RFC 2296)? Or are you
considering that, if the client attempts all the highest-priority
alternates and they fail, it can then move onto the lower priorities?


It can be debated whether clients can retry to a different server requests
> not having any side effects, but in that case the algorithm should be
> pretty much the same as in the first round, after invalidating the failed
> server(s).
>
> I would not overload max-age however with this task however. If a "q="
> parameter can be added, it should be possible to add a "max-age=" parameter
> as well, isn't it? Unless the proposal is to define some mechanism to clear
> the list of altsvc regardless of any other expiry information.
>

There's already a max-age ("ma") parameter "which indicates the number of
seconds [...] the alternative service is considered fresh for", the default
being 24 hours. Setting it to 0 automatically marks the alternate service
as stale, which I suppose means it's no longer available. That means being
able to send a second Alt-Svc header with the same [protocol,host,port]
tuple, but with "ma=0".


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/