Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alt-Svc-Used indicator granularity #34

enygren opened this issue Aug 22, 2014 · 4 comments


None yet
3 participants
Copy link

commented Aug 22, 2014

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.


Regardless of how this is resolved, there is still text referring to previous Alt-Svc-Used indicator proposals that should be cleaned up to be consistent with whatever we decide on. For example, with the current text the following is confusing and should be removed:

To reduce the ability of servers to track individual clients over time (see ), an alternative service indication sent by a client &SHOULD-NOT; include
any alternative service information other than the protocol, host and port.

(as the protocol, host, and port aren't part of what is being sent in the current indication).

The same applies of the "Tracking Clients Using Alternative Services" section which may be a remnant from previous versions.

The current text also mentions a "token" in the Alt-Svc-Used definition, but does not explain it or specify how it might be used or set.

@mnot mnot added alt-svc labels Aug 26, 2014


This comment has been minimized.

Copy link

commented Oct 25, 2014

I'm going to remove the text from the Alt-Used definition that is out of date.

I don't see any occurrence of "token" that shouldn't be there.

WRT "Tracking Clients Using Alternative Services" - can we get rid of that consideration altogether now that we only have 0 and 1?

reschke added a commit that referenced this issue Oct 25, 2014


This comment has been minimized.

Copy link

commented Oct 27, 2014

I don't think we can get rid of that consideration; the alt-svc hostname can still encode a significant amount of information.


This comment has been minimized.

Copy link

commented Oct 27, 2014

I rephrased it assuming we were talking about one additional bit.

So yes, we need to keep it and explain the issue caused by the hostname choice.


This comment has been minimized.

Copy link

commented Nov 11, 2014

Discussed in Honolulu;

  • no alt-svc-used indicator (some support)
  • 1-bit (no hum!)
  • multi-bit
  • full hostname (some support)
  • 1-bit or full-hostname (some support)

"Doesn't know" wins

reschke added a commit that referenced this issue Jan 30, 2015

@reschke reschke closed this Feb 5, 2015

reschke added a commit that referenced this issue Oct 7, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.