Re: HTTP router point-of-view concerns
Willy Tarreau <w@1wt.eu> Fri, 12 July 2013 12:59 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D8A21E8093 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2013 05:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boKnPKPv6LsW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2013 05:59:17 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0721F9E88 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 12 Jul 2013 05:59:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uxcvi-0000p8-5L for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2013 12:58:34 +0000
Resent-Date: Fri, 12 Jul 2013 12:58:34 +0000
Resent-Message-Id: <E1Uxcvi-0000p8-5L@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1Uxcva-0000mI-77 for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2013 12:58:26 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UxcvW-0000Z5-UH for ietf-http-wg@w3.org; Fri, 12 Jul 2013 12:58:26 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r6CCuSrT030294; Fri, 12 Jul 2013 14:56:28 +0200
Date: Fri, 12 Jul 2013 14:56:28 +0200
From: Willy Tarreau <w@1wt.eu>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mark Nottingham <mnot@mnot.net>, Sam Pullara <spullara@gmail.com>, James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20130712125628.GC28893@1wt.eu>
References: <CA+qvzFPUpcm6kUtJx+rTw8Dpp4Gtx4Bmr3XPDhjNsjchUfN9_w@mail.gmail.com> <51DE1E32.9010801@treenet.co.nz> <CAP+FsNdcYhA=V5Z+zbt70b5e7WmcmXgjG5M9L3vfXeXfTwmRnw@mail.gmail.com> <51DE327C.7010901@treenet.co.nz> <CABkgnnXeqD6wh0dcJ1Dz=4PLAJNkDeGcCuzMr9ATd_7xS7nbGQ@mail.gmail.com> <CABP7RbcUkLf3CTAB4jwicnsiKWLGVY6=hX0k=0256SR_gcVt9A@mail.gmail.com> <092D65A8-8CB7-419D-B6A4-77CAE40A0026@gmail.com> <3835.1373612286@critter.freebsd.dk> <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net> <1772.1373629495@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1772.1373629495@critter.freebsd.dk>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Hub-Spam-Report: AWL=-2.908, RP_MATCHES_RCVD=-0.303, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UxcvW-0000Z5-UH b466287312d76ae9457464bff084b4d7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/20130712125628.GC28893@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18724
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>
Hi Poul-Henning, On Fri, Jul 12, 2013 at 11:44:55AM +0000, Poul-Henning Kamp wrote: > In message <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net>, Mark Nottingham wri > tes: > > >This has been brought up a number of times. I think what we need is a = > >concrete proposal *with* a detailed plan for a workable transition to = > >the new mechanism -- which seems to be the (or at least one) sticking = > >point whenever this comes up. > > I have given a concrete example multiple times, it's very simple: > > The client always sends along a session-identifier of N (128?) > bits. > > If the first bit is zero, this is an anonymous, transient > session, not (to be) associated with any other session. > > If the first bit is one, this is a persistent session > identifier, which the server can use to look up any relevant > state or information from previous instances of this > session, in its local database. > > This replaces the Cookie: and Set-Cookie: headers, which > SHALL NOT be sent in the HTTP/2.0 protocol. > > Advantages: > > We get a fixed size session-identifier for HTTP routers to > use for flow-routing. > > We get an actual (client controlled) session-concept, rather > than all sorts of ad-hoc simulations with cookies. > > Data with privacy-concerns are stored on the server not on > random clients the user happens to borrow or use. > > The overhead of encrypting and signing the data in cookies > is avoided, since they are stored on the server side where > nobody can fudge them. > > Backwards compatibility: > > It should be obvious that simulating the Cookie concept for > framework compatibility on the server side is a trivial > matter of programming: Rather than send set-cookies, write > them to a database, indexed by the session-id. Rather than > receive Cookie: headers, look them up in the database. > > There, solved. Not really in fact. While I tend to generally agree with the points you make for scalability, this one does not scale. One of the big benefits of cookies is that client is responsible for synchronizing information between multiple servers *if needed*. When you're building an architecture using anycast DNS + ECMP + L4 load balancers to reach your servers, you can't predict if a client will come back to the same place to retrieve its context, and having the ability to make it hold *some* data is really useful. If you store everything on server-side, you're forced to synchronize everything between all servers of all datacenters because you don't even know where your client will go with next hit, let alone parallel requests. And this is clearly not possible on many of the platforms where both of our products are deployed to achieve connection rates in the 6 digits. So there *is* some use to store data on the client, it's just that it has been long abused to store session identifiers because it was the only mechanism available. While I'd like to see a simple session management system (like the one you propose maybe, even if it does not cover the case of low entropy client devices), I don't want to see the cookies disappear. I just want to be able to rely on session ID without having to parse cookies when that's not needed. Regards, Willy
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Michael Sweet
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Patrick McManus
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Mark Nottingham
- Re: HTTP router point-of-view concerns Mike Belshe
- Re: HTTP router point-of-view concerns Gábor Molnár
- Re: HTTP router point-of-view concerns Gábor Molnár
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Michael Sweet
- Re: HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Patrick McManus
- Re: HTTP router point-of-view concerns Jeff Pinner
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Ludin, Stephen
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Mark Delany
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Stephen Farrell
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Martin Nilsson
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Nico Williams