Re: Alt-Svc-Used indicator granularity (ext#34)
Martin Thomson <martin.thomson@gmail.com> Sat, 23 August 2014 00:09 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D341A04F8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Aug 2014 17:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.67
X-Spam-Level:
X-Spam-Status: No, score=-7.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhp6q406crDJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Aug 2014 17:09:24 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF1D1A032D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 22 Aug 2014 17:09:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XKyr9-0004VU-P0 for ietf-http-wg-dist@listhub.w3.org; Sat, 23 Aug 2014 00:06:55 +0000
Resent-Date: Sat, 23 Aug 2014 00:06:55 +0000
Resent-Message-Id: <E1XKyr9-0004VU-P0@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XKyqr-0004TV-2T for ietf-http-wg@listhub.w3.org; Sat, 23 Aug 2014 00:06:37 +0000
Received: from mail-lb0-f174.google.com ([209.85.217.174]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XKyqp-0005d7-U0 for ietf-http-wg@w3.org; Sat, 23 Aug 2014 00:06:37 +0000
Received: by mail-lb0-f174.google.com with SMTP id c11so10222589lbj.33 for <ietf-http-wg@w3.org>; Fri, 22 Aug 2014 17:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xbQa3S60zKPMI/qsw1HaXaP7vHrN2cIAIik3Y3+RAfw=; b=mShPqT+WEPit2Qa9q2ny98TmH7gmXhoCfXa6sn2QPUAIsr2eIKgBauopev4bMqYzMd 2bQCOEKv85Xl2kfgdY7zxNDSvaNn6uCVa4wGPRwf+Afl0NN+6dT71dASny+VbfjB4r6S HKzm6wnH0U2zg2Pa4DattUyHARIHdLQ0WVAiUjNrMDylz0UqgNE5xqE36hpvA8Wrrd6H ziKzbRkGEaPKmzBOq2lVdkO1L099kowkvubJBgvz6oibJ8JEjh3+yk4/eode5BCkr5ul o5HFPL6whMBa4OwGx5B6J4qcnSCvznvBhsJVtwn1GAkSVK1itX3Zk3clQ2LAdKP56jxN zNvg==
MIME-Version: 1.0
X-Received: by 10.152.19.5 with SMTP id a5mr7372117lae.21.1408752369063; Fri, 22 Aug 2014 17:06:09 -0700 (PDT)
Received: by 10.25.166.75 with HTTP; Fri, 22 Aug 2014 17:06:09 -0700 (PDT)
In-Reply-To: <CAKC-DJiKg4OopATYgjcO7SBPNJ7t6+LA1bPWemjXL8e54gwrsw@mail.gmail.com>
References: <CAKC-DJiKg4OopATYgjcO7SBPNJ7t6+LA1bPWemjXL8e54gwrsw@mail.gmail.com>
Date: Fri, 22 Aug 2014 17:06:09 -0700
Message-ID: <CABkgnnW7GnPYP4WY-9SKC8pMCuUS=9wvYcAYp-OTJp8_m0CsUg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Erik Nygren <erik@nygren.org>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.217.174; envelope-from=martin.thomson@gmail.com; helo=mail-lb0-f174.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.722, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1XKyqp-0005d7-U0 9f2045411f8bb7e9e312c4f13bcc1404
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Alt-Svc-Used indicator granularity (ext#34)
Archived-At: <http://www.w3.org/mid/CABkgnnW7GnPYP4WY-9SKC8pMCuUS=9wvYcAYp-OTJp8_m0CsUg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26716
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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.) > >
- Alt-Svc-Used indicator granularity (ext#34) Erik Nygren
- Re: Alt-Svc-Used indicator granularity (ext#34) Martin Thomson
- Re: Alt-Svc-Used indicator granularity (ext#34) Erik Nygren
- Re: Alt-Svc-Used indicator granularity (ext#34) Erik Nygren