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

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

From: Erik Nygren <erik@nygren.org>
Date: Fri, 22 Aug 2014 18:38:08 -0400
Message-ID: <CAKC-DJiKg4OopATYgjcO7SBPNJ7t6+LA1bPWemjXL8e54gwrsw@mail.gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 Friday, 22 August 2014 22:38:34 UTC

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