Re: HTTP router point-of-view concerns

Nico Williams <> Thu, 18 July 2013 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B739821F889C for <>; Wed, 17 Jul 2013 17:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=3.407, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z3YyF8DBs-Vk for <>; Wed, 17 Jul 2013 17:07:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D3DF21F888F for <>; Wed, 17 Jul 2013 17:07:59 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UzbjM-0003fi-I1 for; Thu, 18 Jul 2013 00:06:00 +0000
Resent-Date: Thu, 18 Jul 2013 00:06:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uzbj4-0003ev-K7 for; Thu, 18 Jul 2013 00:05:42 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1Uzbj3-0006Hm-K7 for; Thu, 18 Jul 2013 00:05:42 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 616BC2916C3 for <>; Wed, 17 Jul 2013 17:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=3pO3mQ2Kr0gLhADYktS1 Ozj54aE=; b=Hh4bU/H8xmB6VBBHKSqnzF+5bIs5weMwLfEcZMBRoJGeLiYtEA54 ALuH86PNA4Cb6PFUPSKty9gR+uo2roMnZ58gKnIjyWOScSDvPNU4R/UWK7Hd5TBp Sc1GjNfbTOi3hTihKo6e9iz0y/1ly+MjLqi2B03Tx6SPJB+2Ce+tSBc=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 081812916C1 for <>; Wed, 17 Jul 2013 17:05:19 -0700 (PDT)
Received: by with SMTP id k10so2598299wiv.17 for <>; Wed, 17 Jul 2013 17:05:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KTkD68QIEGd7BGGP/0a8cqsUAVS3P+iybH07ATzfL5c=; b=axWPc/CBB8rKqF6s5aWNLPFtc6mgZqdHFbs07Yy0CZLm9f/l/GSiuvLk3OombRqhRu yv6b6JZ7r7GOmhgUPV8B8Te+ni9Q/RjVeulOTXX0U+fdNMSFItEOy+XXDu8WwlSPSxjY Gxb1xIjkAzYq4lD80W3FGn8vJoawrfY2BfUfNr6ClKheP654RgOfHN/CoW4DABsYMkJ/ NJyOEbMwhc+hREvyGHHsSE/YroGJ+HKQP+vVttAJZQC0u9UgYzTlyDGP9EDTzDsQuC29 AnRghDgQyh1vX5JQi9EX9D2n1XhwDCxx/a9YLaIICzZWByQcZNRTpTjQiEvDTDoiR+1L 0hqA==
MIME-Version: 1.0
X-Received: by with SMTP id w6mr6248628wiy.36.1374105918299; Wed, 17 Jul 2013 17:05:18 -0700 (PDT)
Received: by with HTTP; Wed, 17 Jul 2013 17:05:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 17 Jul 2013 19:05:18 -0500
Message-ID: <>
From: Nico Williams <>
To: Poul-Henning Kamp <>
Cc: Sam Pullara <>, James M Snell <>, Martin Thomson <>, Amos Jeffries <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.449, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1Uzbj3-0006Hm-K7 d9bacc6d75162a0083cd502aea54208a
Subject: Re: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18835
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Jul 12, 2013 at 1:58 AM, Poul-Henning Kamp <> wrote:
> In message <>, Sam Pullara writes
>>How sure are we that the entire idea of header compression isn't a bad

Me three.

> I'm entirely convinced it is a bad idea.
> The main gain that can be had from it, is compressing cookies and
> that issue should be solved by moving the cookies onto the server,
> indexed by a client provided session-id.

As for [encrypted] session state cookies, there is a trade-off: state
on the server vs. not.

Some state kept by the application on the server side can be cached,
using the client to hold the [encrypted] sub-state cookies and re-send
as necessary (e.g., if the server pushes the client's state out of its
cache).  Obviously this doesn't apply to long-term state (e.g., files
stored on a cloud), just session metadata, nor does it apply to
frequently-changing session state: that just consumes bandwidth --
much more than it would consume memory to just keep around.  But much
session state needs to be able to be pushed out of the server's cache
(e.g., not shopping carts in some apps, but yes in others).

The right balance, IMO, is for the server to assign as small a session
ID as it can (it can be smaller if a "connection" can be used as part
of a lookup index, else it has to be bigger).  Traditionally HTTP/1.x
services haven't really been able to associate state with
"connections", and I find it odd that we'd try to do it in HTTP/2.0.