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

Hi Matthew.,

On Jul 3, 2014 8:11 AM, "Matthew Kerwin" <matthew@kerwin.net.au> wrote:
>
> 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?

I'm suggesting the latter. See the use case I gave in a different mail in
this thread.

>
>
>> 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".

Thanks for clarifying this for me. This would of course work.