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.
Editorial
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.
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:
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.
Editorial
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:
(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.