Re: HTTP router point-of-view concerns

Sam Pullara <> Thu, 11 July 2013 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA9EE21F9A83 for <>; Thu, 11 Jul 2013 12:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CrBrON+BOX1E for <>; Thu, 11 Jul 2013 12:22:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D692721F9B5C for <>; Thu, 11 Jul 2013 12:22:39 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UxMQM-0000Gu-Ik for; Thu, 11 Jul 2013 19:21:06 +0000
Resent-Date: Thu, 11 Jul 2013 19:21:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UxMQC-0000Fs-Dr for; Thu, 11 Jul 2013 19:20:56 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UxMQB-00009b-Dr for; Thu, 11 Jul 2013 19:20:56 +0000
Received: by with SMTP id 14so7847539pdj.12 for <>; Thu, 11 Jul 2013 12:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=q/ZDf+2bAVtXsDwA3op58R0bCc0+XNL2WGHbjeIoG3A=; b=wCMSNXzCmVtglr9Lt6i3SM6KG2aAK+m9zAWP5BiHdhFgph0ZxckRxjW/Pjl3nqGZHH 2W1/vKS2eiY0uKBcM/LzDBZfOOzRq1eHrygGj129rdxnBCUyIIIQJeTrkULWTOe8oQ3+ 6nnr45JJWFLO3zMrSuP2mTMULHWhbpkkV4T5K5QqyszrnIl6K+TdXx4QACfgX3p4LAL+ LEJyUhYVm4TFCMe21VAsssP0qZx7B0bWs9VvlaIpeEj9vRgPcj/A2YQV6ihpUdOocYsh p6YfXQopX3ZczHuV/o5vUGLwQ8OfgTCLknSMQoYBx/8ALB8ZY8tKXTQR/AlHDZWzR+vl qhbQ==
X-Received: by with SMTP id n1mr39816421pae.93.1373570429000; Thu, 11 Jul 2013 12:20:29 -0700 (PDT)
Received: from ( []) by with ESMTPSA id qg10sm11403928pbb.2.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 12:20:28 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Sam Pullara <>
In-Reply-To: <>
Date: Thu, 11 Jul 2013 10:21:00 -0700
Cc: Martin Thomson <>, Amos Jeffries <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: James M Snell <>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Hub-Spam-Report: AWL=-3.061, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UxMQB-00009b-Dr 43bacd0ab0bf0c9a576a831bd6b760ba
Subject: Re: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18700
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

How sure are we that the entire idea of header compression isn't a bad idea? I implemented something similar in the WebLogic T3 protocol (BubblingAbbrevTable, probably still in there) and it was mostly just a pain. If I were to go back I would just use gzip with some agreed upon seed dictionary. Thought I would bring this up since it seems like it is a very controversial feature to begin with.


On Jul 11, 2013, at 10:14 AM, James M Snell <> wrote:

> Yes, the ability to set compression context size to 0 is very useful.
> My fears around this area are:
> 1. In order to achieve maximum throughput, Intermediaries may opt to
> *always* set compression context to 0, forcing the headers to always
> be passed as Literals, killing the utility of having the header
> compression mechanism there in the first place.
> 2. The assumption of a non-zero default compression context size when
> the connection is established opens a race condition that a malicious
> sender could exploit in a denial of service attack. Yes, the receiver
> could opt to terminate the connection once it detects bad behavior,
> but there is still a potential window of time there where the receiver
> could be forced to do significant additional work.
>  (This is particularly bad given that header continuations are unbounded.)
> 3. Setting the compression context size to 0 does not stop the sender
> from sending the Indexed Literal instructions anyway. The receiving
> endpoint would still be required to process those instructions even if
> the data is not actually being indexed, causing CPU cycles to be
> consumed. For any individual block of headers it may not be a
> significant load, but it's something that needs to be addressed.
>  (This can be fixed in the spec by stating that any attempt to Index
> any individual (name,value) whose size is greater than the available
> header table size results in a Compression Error. Making this change
> would mean that when Compression Context size is 0, the only operation
> that would not result in an error is Literal without Indexing. This
> was discussed on the list but as far as I can tell it's not yet
> captured in the spec).
> 4. The fact that header continuations can be unbounded is deeply
> troubling, especially given that the endpoint is required to buffer
> and process the complete header block (well.. that's only half true,
> the encoding does allow for incremental processing of the HEADERS
> frame payloads but the spec requires that the complete header block is
> always processed). Sure, the recipient is free to terminate the
> connection as soon as it detects bad behavior, but the sender could
> end up forcing the recipient to do a significant amount of extra
> processing with a never ending sequence of HEADERS frames. Smart
> implementations will know how to deal with this, yes, but overall it
> adds to the already growing list of "New Complex Things" that an
> HTTP/2 implementer needs to know about.
>  (In the implementation I've done, I provide a configuration
> parameter that allows a developer to cap the number of the
> continuations and the total size of the header block)
> I know that we're in "implementation" phase right now and that
> everyone is busy getting their code ready for testing in August, but
> after updating my implementation to the latest version of the draft,
> my concerns with regards to stateful header compression definitely
> remain.
> On Thu, Jul 11, 2013 at 9:36 AM, Martin Thomson
> <> wrote:
>> On 10 July 2013 21:20, Amos Jeffries <> wrote:
>>> It seems not to be negotiable from the recipients side.
>> Compression context size = 0 is entirely negotiable from the recipient
>> end, with a small wrinkle, that I know some folks are working on.
>> Which is, a client can start using a default compression context size
>> prior to learning that a server has no space (substitute intermediary
>> as appropriate there).