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

Kazuho Oku <kazuhooku@gmail.com> Thu, 03 November 2016 01:59 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 BC1DB1296D7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Nov 2016 18:59:10 -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 (2048-bit key) header.d=gmail.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 JLQdxD8NHnVN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Nov 2016 18:59:09 -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 95986127078 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 2 Nov 2016 18:59:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c27FE-0008U2-FV for ietf-http-wg-dist@listhub.w3.org; Thu, 03 Nov 2016 01:55:08 +0000
Resent-Date: Thu, 03 Nov 2016 01:55:08 +0000
Resent-Message-Id: <E1c27FE-0008U2-FV@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1c27F8-0006iT-Vj for ietf-http-wg@listhub.w3.org; Thu, 03 Nov 2016 01:55:03 +0000
Received: from mail-wm0-f48.google.com ([74.125.82.48]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <kazuhooku@gmail.com>) id 1c27F2-0006R6-T8 for ietf-http-wg@w3.org; Thu, 03 Nov 2016 01:54:57 +0000
Received: by mail-wm0-f48.google.com with SMTP id p190so303895861wmp.1 for <ietf-http-wg@w3.org>; Wed, 02 Nov 2016 18:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AV2zQXe1SzJoM7+EvWXQ7UhXjhHBAroQcH69gE4HKmM=; b=j2nlWMi0PVtdD96FSohx5/BvkoNAbI3e+/27nY3Tk9gtl6TytwTk+IHGG3+NskMNUJ f57abcIAWGBFL/sRibAAmFzKLekMzNst9IgdMMb1eMmG561kYxx+K4oneU0eU0KMC+6G Oj0blD5XSPzAycP0KYdbj5hMi9/sHCG0OeGUyKc0ovtUNfUjHjGsJv6kTHnn06qLCLKY c7It8UsqBCzMcGn0bCr0Mv7bVs6WYg5srUEdfgVgFEMyoYBL3apFt5X1JTd8LsMoQbFF NI5yS10VCe+1Ue1Dg7jdd+ZmsYX0mLJqWIgBi9iY8HsO1hOFAe1lx8rSWTOVY5rHXW4A 2LMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AV2zQXe1SzJoM7+EvWXQ7UhXjhHBAroQcH69gE4HKmM=; b=Rsy/3T5bTiKdM4lcuwZNeuQTVefZqqONVHGgIPNQJfDoPIs/T05PxhxXfC4poYSYRp S9Nqf8ZKFirxldY/tvaThoEkEWSrTtly+TdqIf7yTqImiTJRueGJu9KNcilzDv7GMkSy 8eeYSV0R8661PliPKOZmqRBVRDG5fj4Fe4EAYlCIrhi+cMsQnR1U0jggO3b9nNdeu7+4 KgAxM5f0x78OhlwV9cwT2d+lHPkxnwxRsRcNe7xS8SOeSoVMFglq5YO2l05TGx5hGBIh Cs8Ohh95H5qfDedK+InsLiyX70v8JOYbh4vKdfwduiinOeG2ypTAHzbEufAnK9ny8xr0 1Zvg==
X-Gm-Message-State: ABUngvcKYdlzoL5lLjvah+aUFmcgwgL9Qwb8e5yxr9K2Tq9VUuZchO4NdxGm/EpYqLM6noD1kF/LaRTP5IjgGA==
X-Received: by 10.194.155.35 with SMTP id vt3mr5017215wjb.223.1478138070237; Wed, 02 Nov 2016 18:54:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Wed, 2 Nov 2016 18:54:29 -0700 (PDT)
In-Reply-To: <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> <D8E74F06-A6CC-4EA9-9D7C-EFD043F72624@cloudflare.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 3 Nov 2016 10:54:29 +0900
Message-ID: <CANatvzzZOvPWrdQqNfV4VSiZ4cb2zt36f1-mKTrxTS8kW6eSuw@mail.gmail.com>
To: Vlad Krasnov <vlad@cloudflare.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=74.125.82.48; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.292, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c27F2-0006R6-T8 69479d22ba60da30276510abdafdaed6
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/CANatvzzZOvPWrdQqNfV4VSiZ4cb2zt36f1-mKTrxTS8kW6eSuw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32826
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>

2016-11-03 10:23 GMT+09:00 Vlad Krasnov <vlad@cloudflare.com>om>:
>
>> 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.

I agree with Martin that using an HTTP header for the purpose is not a
good idea.

One practical issue I am afraid of using Content-Encoding for such
purpose is that the checksum of the transferred file becomes different
from the original, since there is no deterministic way to reconstruct
the compressed form of a gzip. The draft alters some part of the
response (e.g. first 32KB after decompressed), and it is impossible
for a client to reconstruct how it looked like on the origin server
(under the compressed form).

I think this would cause interoperability issues due to the fact that
sometimes the checksum (or a signature) of a transmitted archive is
transferred separately.

Using transfer-encoding header would not cause this issue, but I think
things would become simpler if the identifier of the compression
method being applied was transmitted as an HTTP/2 frame rather than a
HTTP header.

Personally, I wonder if the approach could be adjusted to using a
shared compression context between the DATA frames of multiple
streams. Doing that way, the draft would become more attractive to
other use-cases (e.g. JSON API in microservices) where many tiny
responses are sent very frequently. Even if we changed the draft as
such, a server could still use the trailing part of a pre-compressed
file, by locking down the response being transmitted to that
particular one.

Anyways, I am looking forward to discussing the I-D at IETF, since I
think there'd be value in solving the issue (that the I-D tries to
solve).



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



-- 
Kazuho Oku