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

On 2 Jul 2014, at 4:54 pm, Matthew Kerwin <matthew@kerwin.net.au> wrote:

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

Yes, any parameter is allowed, but ‘q’ is only a convention; it doesn’t have any meaning unless the header defines it.

So far, we see ‘q’ being paid only scant attention in existing headers; not sure it’ll really be better here. Again, the original scheme did have a prioritisation mechanism, but the feedback I got was that it’s too complex for no demonstrated gain.


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


--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 3 July 2014 00:22:57 UTC