Re: New Version Notification for draft-vkrasnov-h2-compression-dictionaries-01.txt

Vlad Krasnov <vlad@cloudflare.com> Thu, 03 November 2016 01:28 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 888611297DE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Nov 2016 18:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASpNht2OPsum for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Nov 2016 18:28:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86D01297AA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 2 Nov 2016 18:28:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c26lN-0003Np-LW for ietf-http-wg-dist@listhub.w3.org; Thu, 03 Nov 2016 01:24:17 +0000
Resent-Date: Thu, 03 Nov 2016 01:24:17 +0000
Resent-Message-Id: <E1c26lN-0003Np-LW@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vlad@cloudflare.com>) id 1c26lH-0003N0-4A for ietf-http-wg@listhub.w3.org; Thu, 03 Nov 2016 01:24:11 +0000
Received: from mail-pf0-f171.google.com ([209.85.192.171]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <vlad@cloudflare.com>) id 1c26lB-0002FZ-8C for ietf-http-wg@w3.org; Thu, 03 Nov 2016 01:24:05 +0000
Received: by mail-pf0-f171.google.com with SMTP id n85so21260363pfi.1 for <ietf-http-wg@w3.org>; Wed, 02 Nov 2016 18:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KoOBeGPyhR8Z6aGum9Z2RA2LqueXL+b60J3/NgRl29U=; b=CruMDbKEuXyg1QDmJyM2C1KfvetZ3bun3QcyGGiywwmYxHEzWvpIKnSaGi9BOWjm2A 4NXFa1TidIflHIWrVRKWLLnOFVnckd78YIHuPPQ1CU6lq898TDFK/ps5CTxY9Q/cPPT2 z1aMWhS+3JIHaOOVasJ4HTGt4ihvEIpdrCd6M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KoOBeGPyhR8Z6aGum9Z2RA2LqueXL+b60J3/NgRl29U=; b=UM31B69IyILbpzgEwGBEa7zBaFeN6E8ClS/qaVg+UWCpBOI2t/AHLgLs8MIMfP17YC TUxTp+f3lhDginuwfk66XWNAjGi5xxZEukaZhXodJ3ICLb6LnAhTqi0WXtWtyb6X9MJ4 lD1Xdv3ui/fywfZQgVdaIlfxgBc3au7XQOKM/tTNxXJEK789lRfKSDgo4XP/u9FxI5Ec jpK01lUaVe72OkDy0ibVbrSnvQ7g8J2hnSarNM59A7UT8oLN0pfkE0b7KqDIGvOYJeyS KFG6MAaPcVRWTO8ZFimUYenjFM3re9IfymKdJBESUcam9ju09qj+CqqxLr/PYva9BhmN LK9g==
X-Gm-Message-State: ABUngve5XeBbVr8lzW49UL4RPhC4ibLGCMR8P0pV8m6jumJDTdyhtCOZbWBzUZN4YybtQMlS
X-Received: by 10.99.143.2 with SMTP id n2mr10010286pgd.70.1478136218030; Wed, 02 Nov 2016 18:23:38 -0700 (PDT)
Received: from ?IPv6:2601:645:8302:ef30:1c3e:31b5:e169:77b6? ([2601:645:8302:ef30:1c3e:31b5:e169:77b6]) by smtp.gmail.com with ESMTPSA id b66sm7585624pfg.10.2016.11.02.18.23.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Nov 2016 18:23:37 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Vlad Krasnov <vlad@cloudflare.com>
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <CABkgnnWFds=rYHc-ufCynXg701ekQ6MJTrbXXZrV0ozRod6HzA@mail.gmail.com>
Date: Wed, 2 Nov 2016 18:23:36 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8E74F06-A6CC-4EA9-9D7C-EFD043F72624@cloudflare.com>
References: <147793576451.32369.14134057573457350871.idtracker@ietfa.amsl.com> <3669167D-26AC-4B78-8175-99B0028B6891@cloudflare.com> <CABkgnnXqHP6RNpHBcFStO5TWz8Sq6Uqs7KMWFof88RjxhoW-Qg@mail.gmail.com> <06396a0d-a0c1-19fc-85d5-6ddfb9bcf39f@gmx.de> <CABkgnnWFds=rYHc-ufCynXg701ekQ6MJTrbXXZrV0ozRod6HzA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Received-SPF: pass client-ip=209.85.192.171; envelope-from=vlad@cloudflare.com; helo=mail-pf0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c26lB-0002FZ-8C 6aece2f0c44e0f3e8474e93965213506
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-vkrasnov-h2-compression-dictionaries-01.txt
Archived-At: <http://www.w3.org/mid/D8E74F06-A6CC-4EA9-9D7C-EFD043F72624@cloudflare.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32825
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 Nov 2, 2016, at 5:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
>> 
>> What?
> 
> HTTP/2 - at the layer Vlad is talking about - only knows about the
> bytes that comprise a request or response.  What Vlad proposes
> requires that the HTTP/2 layer look at the Content-Encoding header
> field, determine that it *ends* with a compatible value and only then
> do things to feed data to the compressor.  That's a massive
> architectural upheaval.

I know that it is not entirely "canonical" however even if implemented entirely at the protocol level, http/2 still has to know that no other content-encoding was used at the application layer.

At least from nginx viewpoint this is very simple, but I did not really consider how difficult it might be to implement in FF.