W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Kinkie <gkinkie@gmail.com>
Date: Thu, 3 Jul 2014 07:02:52 +0200
Message-ID: <CA+Y8hcNbF23MCvTj5O4xyig_EjX0FD=qwK6oHsS42QbYq_EOng@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jul 2, 2014 at 7:02 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
> On 1 July 2014 23:22, Mark Nottingham <mnot@mnot.net> wrote:
>> Martin opened two similar issues:
>> <https://github.com/httpwg/http-extensions/issues/7>
>> <https://github.com/httpwg/http-extensions/issues/8>
>>
>> ... regarding how to handle multiple advertised alternative services.
>>
>> Personally, I'm not sure we need to specify this (see my comments in the
issues).
>>
>> What do others think? Martin, any further thoughts?
>
>
> I think that we probably need to have text to clarify what each means,
> but it should be relatively simple:
>
> In both cases, I think that we can say that each advertisement of an
> alternative service adds a new alternative to the set of alternatives
> that is known to the client/recipient.
>
> Then, when multiple alternatives are present, we let the client choose
> the alternative it likes best.
>
> Existing alternatives can have properties altered by selecting based
> on the tuple [protocol, host, port] and providing new values for other
> attributes. Here I'm thinking that we enable forcibly expiring an
> alternative by adjusting max-age.
>
> I'm happy to provide a PR (or three) to this effect.

To me this sounds like a step back compared to DNS SRV records, which offer
priority, weight and ttl.
https://github.com/httpwg/http-extensions/issues/7 suggests extending by
adding a "q=" parameter. IMHO that proposal is useful.
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.

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.

-- 
Francesco
Received on Thursday, 3 July 2014 05:03:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC