Re: Header Compression

Roberto Peon <grmocg@gmail.com> Fri, 21 June 2013 22:52 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 A0DBE21F9D22 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 21 Jun 2013 15:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.573
X-Spam-Level:
X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 F0Z238Al3FLN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 21 Jun 2013 15:52:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A703F21F9D21 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 21 Jun 2013 15:52:26 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UqABi-0003ky-86 for ietf-http-wg-dist@listhub.w3.org; Fri, 21 Jun 2013 22:52:14 +0000
Resent-Date: Fri, 21 Jun 2013 22:52:14 +0000
Resent-Message-Id: <E1UqABi-0003ky-86@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UqABV-0003ic-8L for ietf-http-wg@listhub.w3.org; Fri, 21 Jun 2013 22:52:01 +0000
Received: from mail-ob0-f172.google.com ([209.85.214.172]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UqABU-0007ED-AR for ietf-http-wg@w3.org; Fri, 21 Jun 2013 22:52:01 +0000
Received: by mail-ob0-f172.google.com with SMTP id wo10so9123886obc.31 for <ietf-http-wg@w3.org>; Fri, 21 Jun 2013 15:51:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=of9BaDDSybmPCsQaTcNN+0pEnKUr7D0o2Ajc1/qPHVs=; b=PsNHU00Fi8G8hxHkVfy1nLs2dCWg4T7LUdsr9VAduv+0eBa+1fhWqdm+FTE8OZDbGc /UoYq7lzpjj0LfhMVrQmv3nurqmuk2008jcl2dNVdUca6b+FZ5JjI6JNG7EEaAN9E/fH z7S6G3vsV0GyJgqimCo1iR0p9MPtivYyZ3vbhbj5GkoCqPKgv4m82hwxkb64tto9g4Yj aZlHwT9uoBV9+o0c72XsE9kOwbFXJ/NSi03fUE75b8Qi7Lri6H5TjisSqyrHuT2fEA1n MVOPDsf9VCgPtqFSsfhzHPHW351VIY2t9p98Y2xfYT7lV4oZwOHsXLKTU5md9wfHX2ox MVJw==
MIME-Version: 1.0
X-Received: by 10.60.55.10 with SMTP id n10mr7518910oep.45.1371855094256; Fri, 21 Jun 2013 15:51:34 -0700 (PDT)
Received: by 10.76.71.10 with HTTP; Fri, 21 Jun 2013 15:51:34 -0700 (PDT)
Received: by 10.76.71.10 with HTTP; Fri, 21 Jun 2013 15:51:34 -0700 (PDT)
In-Reply-To: <CA+9kkMAP1=WUhO71+uienmwK+WWwa0Y+e5uLtsSagnDT1igtCg@mail.gmail.com>
References: <6C71876BDCCD01488E70A2399529D5E516531910@ADELE.crf.canon.fr> <CAJ_4DfTQ=X1RE+4aO58_1h7_sCvhNW19ZTFAC7htA4Tb_5gj8w@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E516532B26@ADELE.crf.canon.fr> <CABkgnnURGjmOTNM=mNKOAdmU0F87Rbs_2jDcGQ3_tAVzofwKrg@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E5165335A6@ADELE.crf.canon.fr> <CA+9kkMAgPWFUVHgZrLuf+1-qtV17hY93-mRwh9-UH04Yw4MhfQ@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E525EC01A3@ADELE.crf.canon.fr> <CA+9kkMAP1=WUhO71+uienmwK+WWwa0Y+e5uLtsSagnDT1igtCg@mail.gmail.com>
Date: Fri, 21 Jun 2013 15:51:34 -0700
Message-ID: <CAP+FsNdAtCb+=7T5nPFb38309Fi6v8xZXxT35=zqgPwm1JwxdQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Hervé Ruellan <herve.ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>, Ryan Hamilton <rch@google.com>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="089e01294b5293a1ba04dfb1e762"
Received-SPF: pass client-ip=209.85.214.172; envelope-from=grmocg@gmail.com; helo=mail-ob0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.688, 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: maggie.w3.org 1UqABU-0007ED-AR 36f85925ac1f22f7fd9fc098765cbe47
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Header Compression
Archived-At: <http://www.w3.org/mid/CAP+FsNdAtCb+=7T5nPFb38309Fi6v8xZXxT35=zqgPwm1JwxdQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18340
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>

I think that you are perhaps confused between deleting something from the
state and deleting something from the headers.

In the former case it is accomplished by replacing an entry with another.
In the latter, it is done by referencing that entry again with an indexed
instruction, causing it to be removed from the set of 'active' headers.

Or, I could be the confused one :)

-=R
On Jun 20, 2013 3:59 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

> On Mon, Jun 17, 2013 at 9:43 AM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr
> > wrote:
>
>>
>> Second, it is a design choice not to have deletion: the mean of removing
>> a header is to replace it with a new one. Another possibility is to use the
>> automatic dropping of headers to remove the headers that were the oldest to
>> be added to the table (see penultimate paragraph of section 3.1 Header
>> Table).
>>
>>
> Sorry for the delay in responding.  Just to make sure I understand:
>
> I have a header "Example: ".  It's in position 3 in the index.  I want to
> remove "Example: ".  To do so, I update position 3 with a new header, say,
> "Fleen: ".  The Fleen header can be a no-op, a duplicate of another header,
> or something I care about now and did not before.
>
> Is that about right?
>
> If so, I don't think the draft is clear on this point.   I think making an
> explicit statement that there is no "delete" operation but that a similar
> aim can be accomplished by updating an index position with a new header,
> including a no-op header, would be useful.
>
> regards,
>
> Ted Hardie
>
>
>
>
>> Hervé.
>>  ------------------------------
>> *From:* Ted Hardie [ted.ietf@gmail.com]
>> *Sent:* Tuesday, June 11, 2013 18:33
>> *To:* RUELLAN Herve
>> *Cc:* Martin Thomson; Ryan Hamilton; ietf-http-wg@w3.org
>> *Subject:* Re: Header Compression
>>
>>  On Tue, Jun 11, 2013 at 7:05 AM, RUELLAN Herve <
>> Herve.Ruellan@crf.canon.fr> wrote:
>>
>>> I just did it :
>>> http://www.ietf.org/id/draft-ruellan-http-header-compression-00.txt
>>>
>>> Hervé.
>>>
>>>
>> Hi Herve,
>>
>> A couple of quick comments.  First, for the TODO in your security
>> considerations section, I think you should probably expand on the text in
>> the overview, which describes the attack on Deflate and unpack why the
>> current scheme is resistant to similar attacks.  Second, the document
>> describes substitution and insertion, but does not describe deletion.   If
>> a party wishes to remove a header (note:  not change to a null value) is
>> this possible and, if so, what's the process?
>>
>> regards,
>>
>> Ted Hardie
>>
>>
>>
>>> > -----Original Message-----
>>> > From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>> > Sent: jeudi 6 juin 2013 18:46
>>> > To: RUELLAN Herve
>>> > Cc: Ryan Hamilton; ietf-http-wg@w3.org
>>> > Subject: Re: Header Compression
>>> >
>>>  > On 6 June 2013 04:43, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
>>> wrote:
>>> > > Yes there are now both HTML and txt version available:
>>> > > http://http2.github.io/compression-spec/compression-spec.html
>>> > > http://http2.github.io/compression-spec/compression-spec.txt
>>> >
>>> > Could you please visit https://datatracker.ietf.org/idst/upload.cgi
>>> > and go through the motions for us.  It's a procedural matter that
>>> shouldn't
>>> > take more than a couple of minutes.
>>>
>>
>>
>