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 08:19:24 +0200
Message-ID: <CA+Y8hcPNtJCXp0U9H0R+Hm3yFh2yLR_aKh5mzqJ108dk5v6giw@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
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.
Received on Thursday, 3 July 2014 06:19:52 UTC

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