Re: Alt-Svc-Used indicator granularity (ext#34)

I can potentially see why it might be interesting to learn about the
difference between shifting load and upgrades of various sorts.  But
if that is all that you need, then we probably want to limit the
information to just that.

Knowing where the information came from is a common marketing
requirement, but separable.  Do you really believe that you will have
so many sources of leads that you will have to have some sort of
...Referer... that allows you to identify bad leads?

Incidentally, based on some other discussions that I've had, I've
basically concluded that the privacy leak isn't much alleviated by the
reduction in entropy on this field, so I'm open to re-opening that
discussion if you feel that would make this more straightforward.  But
I think that I'd still be pushing for a reduction to zero, which would
remove what is a non-trivial disincentive to use Alt-Svc in some use
cases.


On 22 August 2014 15:38, Erik Nygren <erik@nygren.org> wrote:
> For discussion of https://github.com/httpwg/http-extensions/issues/34
>
> -----------------
>
> The current Alt-Svc-Used indicator is a boolean ("0"/"1"), due to the desire
> to preserve privacy.
> Based on some explorations of how this would be implemented on the server
> side, we realized that this doesn't provide enough information to
> distinguish between the different use-cases for Alt-Svc. In particular, a
> server would have no way to know if just the protocol was changed, or if
> both the protocol and host were changed. If we start using multiple Alt-Svc
> sources (such as DNS) this also becomes relevant.
>
> An option short of including (proto,host,port) in Alt-Svc-Used would be to
> include a better indicator of how the Alt-Svc was used. This could be either
> a bitmask or a string of tokens. For example, with a bitmask:
>
> 1 = Alt-Svc was used to change protocol (ie, service proto != default origin
> scheme's proto)
> 2 = Alt-Svc was used to change port (ie, service port != origin port)
> 4 = Alt-Svc was used to change host (ie, service host != origin host)
> 8 = Alt-Svc was obtained via Alt-Svc header
> 16 = Alt-Svc was obtained via ALTSVC frame
> 32 = Alt-Svc was obtained via DNS record (reserved, not yet defined)
>
> With a token approach, short character strings could replace the bitmask.
> In either case this would result in a value like:
>
> Alt-Svc-Used: 20
> Alt-Svc-Used: h,f
>
> For load-balancing, this would make it possible to infer the
> (proto,host,port) that may have been used in cases where it differs by
> use-case but is consistent within a use-case.
>
> This would also significantly help with debuggability on the server side.
>
> (that Issue also mentions some editorial issues that we should resolve after
> answering this.)
>
>

Received on Saturday, 23 August 2014 00:06:37 UTC