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

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

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Wed, 2 Jul 2014 16:54:53 +1000
Message-ID: <CACweHNBQPioyy6W4rS4DZeEfhHYZmD=d=ht3E9PL+ZfiKpLBOw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 2 July 2014 16: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?
Regarding ext#7, if I recall correctly whenever a list includes q-values we
don't tell anyone how to use them, beyond "bigger means better". (RFC
2295/2296 are experimental; does anyone else implement them?) I wouldn't be
against adding q-values to the alt-svc header to indicate a server-side
preference, if such a thing makes sense ("You can also get this here, but
I'd prefer you didn't"..?)

Currently any parameter is allowed, right? Even though only "ma" is defined.

Regarding ext#8, I'm actually interested to see the outcome of the decision
because my draft for compressed DATA frames has an equivalent "single
setting, multiple encodings" issue. If ALTSVC sets a precedent for updating
(rather than replacing), I'll feel less uncomfortable about my extension
setting -- even if that means moving the setting to Yet Another Frame Type.

  Matthew Kerwin
Received on Wednesday, 2 July 2014 06:55:20 UTC

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