Re: Choosing a header compression algorithm
Roberto Peon <grmocg@gmail.com> Tue, 26 March 2013 00:25 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 B379021F877A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Mar 2013 17:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Level:
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3LVGH3lJ11h5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Mar 2013 17:25:09 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id BF78D21F8775 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Mar 2013 17:25:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UKHfk-0005OO-Cd for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Mar 2013 00:23:28 +0000
Resent-Date: Tue, 26 Mar 2013 00:23:28 +0000
Resent-Message-Id: <E1UKHfk-0005OO-Cd@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UKHfU-0005Mu-LE for ietf-http-wg@listhub.w3.org; Tue, 26 Mar 2013 00:23:12 +0000
Received: from mail-oa0-f48.google.com ([209.85.219.48]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UKHfT-00079S-CT for ietf-http-wg@w3.org; Tue, 26 Mar 2013 00:23:12 +0000
Received: by mail-oa0-f48.google.com with SMTP id j1so6931825oag.7 for <ietf-http-wg@w3.org>; Mon, 25 Mar 2013 17:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4yktbM/06ITTrp+y0sxoC8/G7DWojqQE5yhLyZYoEj4=; b=Lq5vedvyUVZCxgn6qtH5Xx3cZiGtB/ji6GBqYnrzIPRjU+CIIz5OOJfFbeV4pLMVIc lunF+Py2IwiDk3FXepXqPavdQOt5qsrJwC9SKr3ETjXtc2xQYCV01e9rDSiSeVtlZsXr pon3LBJ9OKQut0/82cVmsGscrJPY0nBiAtXdpW4eO0gvLOcBRiO1Ne6FPC1on3XaLHj2 YBSHVdRmKDvt6uqzVa87drWcN7IQ22HVrHhb1nL74hTuhvqd865YWmBs4v4NiQh5t6Hk 0pyKWYAvf8QV58arAYrF/Q5cSC8oIowixp2FeXCm3yN5XLGnODWFBvZgBajTpESmK9g4 JSVA==
MIME-Version: 1.0
X-Received: by 10.60.172.237 with SMTP id bf13mr13091049oec.83.1364257365331; Mon, 25 Mar 2013 17:22:45 -0700 (PDT)
Received: by 10.76.109.72 with HTTP; Mon, 25 Mar 2013 17:22:45 -0700 (PDT)
In-Reply-To: <CAP+FsNdztfCJjvP58ryVXDRgGyGSPO-37gRMjAuwikz2eviBiw@mail.gmail.com>
References: <254AABEE-22B9-418E-81B0-2729902C4413@mnot.net> <A14105FB-ED1A-4B70-8840-9648847BCC3A@mnot.net> <6C71876BDCCD01488E70A2399529D5E5163F3C67@ADELE.crf.canon.fr> <CAP+FsNfFohSwrX2DxthNcnn+wDj6T5W7xpcg4yA56Gvt_nP3_Q@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E5163F3D72@ADELE.crf.canon.fr> <7CA7F3EB-A492-471A-8AC4-23293DD10840@mnot.net> <6C71876BDCCD01488E70A2399529D5E5163F4076@ADELE.crf.canon.fr> <CAP+FsNdztfCJjvP58ryVXDRgGyGSPO-37gRMjAuwikz2eviBiw@mail.gmail.com>
Date: Mon, 25 Mar 2013 17:22:45 -0700
Message-ID: <CAP+FsNdQ7mNbsaAiUqEF22Oh8KMaK3UWUWFzWE=K0jQbkM7t1Q@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, agl@google.com
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="bcaec54b4aa2a4efc504d8c8eb4f"
Received-SPF: pass client-ip=209.85.219.48; envelope-from=grmocg@gmail.com; helo=mail-oa0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.664, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UKHfT-00079S-CT f06b792e3a5d7a8e7daf8c5d36e15a87
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Choosing a header compression algorithm
Archived-At: <http://www.w3.org/mid/CAP+FsNdQ7mNbsaAiUqEF22Oh8KMaK3UWUWFzWE=K0jQbkM7t1Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17139
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>
Herve-- We need an option which disables prefix matching on the HeaderDiff compressor. The strategies I see in the code still allow many headers to be attacked (if they include commas). I believe that it is still possible to probe interesting data out of various fields of the URL, for example, or even cookies, assuming they aren't B64 encoded. -=R On Mon, Mar 25, 2013 at 11:38 AM, Roberto Peon <grmocg@gmail.com> wrote: > There are two obvious strategies here: What we do now, and using what SPDY > does today (share connections if the certs match and DNS resolution of the > new hostname overlaps with those of the current connection). > > -=R > > > On Mon, Mar 25, 2013 at 10:21 AM, RUELLAN Herve < > Herve.Ruellan@crf.canon.fr> wrote: > >> > -----Original Message----- >> > From: Mark Nottingham [mailto:mnot@mnot.net] >> > Sent: lundi 25 mars 2013 06:56 >> > To: RUELLAN Herve >> > Cc: Roberto Peon; ietf-http-wg@w3.org Group >> > Subject: Re: Choosing a header compression algorithm >> > >> > >> > On 23/03/2013, at 5:04 AM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr> >> > wrote: >> > >> > > I think it would be good to move this from the compressors to the >> > streamifier. In addition, it would be interesting to look at a more >> realistic >> > streamifier that could for example unshard hosts (expecting that >> HTTP/2.0 >> > will remove the sharding currently done by server developers). >> > >> > Right now, it combines all requests to the same TLD (according to the >> Public >> > Suffix List) into a single "connection." Do you have a suggestion for >> how to do >> > it better? >> >> I think this should provide some "realistic" results as a starting point. >> Depending on what we want to measure, we may want to refine this a bit. >> >> Hervé. >> >> > I've just pushed a quick and dirty fix to use a new instance of each >> > compressor for each connection; the results are pretty even between >> > headerdiff and delta2, with a small increase in each: >> > >> > * TOTAL: 5948 req messages >> > size time | ratio min max >> std >> > http1 3,460,925 0.18 | 1.00 1.00 1.00 >> 0.00 >> > delta2 (max_byte_size=4096) 707,901 11.87 | 0.20 0.03 0.83 >> 0.15 >> > headerdiff (buffer=4096) 960,106 1.65 | 0.28 0.01 0.96 >> 0.23 >> > >> > * TOTAL: 5948 res messages >> > size time | ratio min max >> std >> > http1 2,186,162 0.28 | 1.00 1.00 1.00 >> 0.00 >> > delta2 (max_byte_size=4096) 622,837 12.86 | 0.28 0.02 1.22 >> 0.13 >> > headerdiff (buffer=4096) 596,290 3.65 | 0.27 0.02 0.92 >> 0.18 >> > >> > Cheers, >> > >> > >> > -- >> > Mark Nottingham http://www.mnot.net/ >> > >> > >> >> >
- Re: Choosing a header compression algorithm Stephen Farrell
- Choosing a header compression algorithm Mark Nottingham
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm James M Snell
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm Mark Nottingham
- Re: Choosing a header compression algorithm Roberto Peon
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm Roberto Peon
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm Martin Thomson
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm Mark Nottingham
- Re: Choosing a header compression algorithm Mark Nottingham
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm Roberto Peon
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm James M Snell
- Re: Choosing a header compression algorithm Roberto Peon
- RE: Choosing a header compression algorithm RUELLAN Herve
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm Roberto Peon
- RE: Choosing a header compression algorithm RUELLAN Herve
- Re: Choosing a header compression algorithm Roberto Peon
- Re: Choosing a header compression algorithm James M Snell