Re: HTTP router point-of-view concerns

Sam Pullara <> Sat, 13 July 2013 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55CE21F9E0C for <>; Sat, 13 Jul 2013 09:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ive22M2yOYqU for <>; Sat, 13 Jul 2013 09:52:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D2B5721F9D2A for <>; Sat, 13 Jul 2013 09:52:08 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uy31b-0003EF-BO for; Sat, 13 Jul 2013 16:50:23 +0000
Resent-Date: Sat, 13 Jul 2013 16:50:23 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uy31R-0003DV-IJ for; Sat, 13 Jul 2013 16:50:13 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Uy31Q-0006oN-O5 for; Sat, 13 Jul 2013 16:50:13 +0000
Received: by with SMTP id ar20so22003062iec.7 for <>; Sat, 13 Jul 2013 09:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=58lgsNH03uz0PN6kcWPk+i2uUE9pYH6Elc6HwXUWupI=; b=J/KS0DCJXTncGpKaBx0V8LR9roVg3PH9KCuYtx36HAmIehoMsaGsr8o14OPxHAX4dC X1ujpAtZcSDkJed95oPj788XAlNYjhFf2MGRxFs7IqslsAgWouJOMrjg21AfRXOWhy9b 1fqXxeGAZn1qKwOlWBCcSdbbM7axiLyZ/wOtgK2l2opq577TWwgKCuyB3w1eOjb1ySU7 82ppciyr2YNpEemOqw1/FmShjl2g1MrC5zT1acvTLVAJlMLIurt2PLddsRt7eJmiWdzd OfrKCLUycngdNI9UjZ0X1AVjnQ5R6QtLDI84mv4/AK71QHKDP8yTUclEf0JMr2Ba9CJA F1DA==
X-Received: by with SMTP id y9mr14364100ics.22.1373734186678; Sat, 13 Jul 2013 09:49:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id vc13sm6429269igb.1.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 09:49:45 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Sam Pullara <>
In-Reply-To: <>
Date: Sat, 13 Jul 2013 09:49:42 -0700
Cc: Poul-Henning Kamp <>, Mark Nottingham <>, James M Snell <>, Martin Thomson <>, Amos Jeffries <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Willy Tarreau <>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.709, 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: 1Uy31Q-0006oN-O5 33860f81b25250384a33cd75997d1bfd
Subject: Re: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18743
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

This can be (and in many cases is already) solved at any web company big enough to need to solve it. I'm 100% in favor of using a client generated session identifier. This would dramatically simplify HTTP/2 in a real way. Cookies are from another era when building a server-side scalable session data store was difficult and expensive. I would argue that isn't the case anymore.


On Jul 12, 2013, at 5:56 AM, Willy Tarreau <> wrote:

> Hi Poul-Henning,
> On Fri, Jul 12, 2013 at 11:44:55AM +0000, Poul-Henning Kamp wrote:
>> In message <>, 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