Re: delta encoding and state management

Willy Tarreau <w@1wt.eu> Thu, 17 January 2013 21:53 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 498CB21F845A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Jan 2013 13:53:05 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CS5pv2JRFpL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Jan 2013 13:53:04 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FE21F8457 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 17 Jan 2013 13:52:59 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TvxNp-0003qd-GK for ietf-http-wg-dist@listhub.w3.org; Thu, 17 Jan 2013 21:52:25 +0000
Resent-Date: Thu, 17 Jan 2013 21:52:25 +0000
Resent-Message-Id: <E1TvxNp-0003qd-GK@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 1TvxNl-0003pt-SS for ietf-http-wg@listhub.w3.org; Thu, 17 Jan 2013 21:52:21 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1TvxNk-0006DV-HV for ietf-http-wg@w3.org; Thu, 17 Jan 2013 21:52:21 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r0HLpmwt032479; Thu, 17 Jan 2013 22:51:48 +0100
Date: Thu, 17 Jan 2013 22:51:48 +0100
From: Willy Tarreau <w@1wt.eu>
To: James M Snell <jasnell@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, Nico Williams <nico@cryptonector.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20130117215148.GA32393@1wt.eu>
References: <CABP7Rbf-_Of0Gnn7uaeuPiiZ6n+MxbpJjbggmD3qjykWX3gaXQ@mail.gmail.com> <CAK3OfOgvK=GEhCr3jghgFu-1FnZLv5j4bmpYoEpsj59kekL5kg@mail.gmail.com> <CAP+FsNcmLH6fWQoptBoP3a1x-zSpbP8piCFz1fg5KuF+6R3jjg@mail.gmail.com> <CAK3OfOj3ZgOZnzcQCifhb9f2One7vBUNGv7yhidkZqRzaeZYvQ@mail.gmail.com> <CAP+FsNfswUN-CK6heRGqEnSJatHGo3q2mZZLTrPnjapCZz2sTg@mail.gmail.com> <CABP7RbfDZcRH-0_AaN9iYjPN-v6QjU6_Xdy5o1BHYnDFWHtuAg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABP7RbfDZcRH-0_AaN9iYjPN-v6QjU6_Xdy5o1BHYnDFWHtuAg@mail.gmail.com>
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.1
X-W3C-Hub-Spam-Report: AWL=-3.059, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1TvxNk-0006DV-HV 26284baea4e3c6696e2f4ceb8316a2b4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: delta encoding and state management
Archived-At: <http://www.w3.org/mid/20130117215148.GA32393@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/15978
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>

On Thu, Jan 17, 2013 at 01:44:42PM -0800, James M Snell wrote:
> On Thu, Jan 17, 2013 at 1:35 PM, Roberto Peon <grmocg@gmail.com> wrote:
> 
> > Here are where my doubts stem from:
> >
> > "Custom" keys and values (cookies, user-agent strings, etc) are added to
> > headers and repeated basically all the time. If we don't know the input a
> > priori, we cannot construct a perfect or minimal encoding.
> >
> > Lets assume we do know about all of the possible header keys and values at
> > the time we create the spec.
> > Even then, we achieve something better than stateful compression only when
> > the sum-total of allowed permutations is less than the amount of bits you
> > need to toggle the visibility on a piece of state (which is very small
> > indeed).
> >
> 
> We certainly cannot come up with optimized binary encodings for everything
> but we can get a good ways down the road optimizing the parts we do know
> about. We've already seen, for instance, that date headers can be optimized
> significantly; and the separation of individual cookie crumbs allows us to
> keep from having to resend the entire cookie whenever just one small part
> changes. I'm certain there are other optimizations we can make without
> feeling like we have to find encodings for everything.

Yes indeed, have referrers relative to URI for example allows stateless
reduction in many cases (but not all) for pages composed of many objects.

Using single-byte for most well-known content types allows Accept to
send shorter lists.

Someone posted the WAP spec a few months ago, it was very useful because
all the research we're talking about was already done there. Even if it
needs some refreshing, the basic concepts of the web and the relation
between headers and their usual subsets of values generally remains.

Regards,
Willy