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

Kazuho Oku <> Thu, 03 November 2016 01:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC1DB1296D7 for <>; Wed, 2 Nov 2016 18:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JLQdxD8NHnVN for <>; Wed, 2 Nov 2016 18:59:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95986127078 for <>; Wed, 2 Nov 2016 18:59:09 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c27FE-0008U2-FV for; Thu, 03 Nov 2016 01:55:08 +0000
Resent-Date: Thu, 03 Nov 2016 01:55:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c27F8-0006iT-Vj for; Thu, 03 Nov 2016 01:55:03 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c27F2-0006R6-T8 for; Thu, 03 Nov 2016 01:54:57 +0000
Received: by with SMTP id p190so303895861wmp.1 for <>; Wed, 02 Nov 2016 18:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id vt3mr5017215wjb.223.1478138070237; Wed, 02 Nov 2016 18:54:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 18:54:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Kazuho Oku <>
Date: Thu, 3 Nov 2016 10:54:29 +0900
Message-ID: <>
To: Vlad Krasnov <>
Cc: Martin Thomson <>, Julian Reschke <>, HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
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: 1c27F2-0006R6-T8 69479d22ba60da30276510abdafdaed6
Subject: Re: New Version Notification for draft-vkrasnov-h2-compression-dictionaries-01.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32826
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2016-11-03 10:23 GMT+09:00 Vlad Krasnov <>om>:
>> On Nov 2, 2016, at 5:06 PM, Martin Thomson <> 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

> 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