Re: HTTP router point-of-view concerns

James M Snell <> Thu, 11 July 2013 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F34F821F9EDB for <>; Thu, 11 Jul 2013 10:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.536
X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RYpm5jjubg5g for <>; Thu, 11 Jul 2013 10:16:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9552321F9EA1 for <>; Thu, 11 Jul 2013 10:16:53 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UxKSy-0006KL-JX for; Thu, 11 Jul 2013 17:15:40 +0000
Resent-Date: Thu, 11 Jul 2013 17:15:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UxKSq-0006Ij-NR for; Thu, 11 Jul 2013 17:15:32 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UxKSm-0003W5-5W for; Thu, 11 Jul 2013 17:15:32 +0000
Received: by with SMTP id n10so11700141oag.0 for <>; Thu, 11 Jul 2013 10:15:02 -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:content-type; bh=E7MUrcrA1YcwfcsmKKEnoW7JpymGarT/esU4DcClCVM=; b=jJ+RhibcYnr0EDbX6/Wi4ZeG2sxAbRMedNE1n1tciCHNs5zkGtHJxt3uBTBHCQAflR FiiDIai1/uD1QGjBiFlgg9RD7rOKahtH3lBR1LqLM2FTZJnCjf7FA9F5x/DLg6FP6j/Q l1XfTHzmIMAx6nfC+D8BCec5z3ULKJZtuef1VBzYDXnn43yWgaSs9sNszq/KcYdtbiig 3Sg5c02ROhe+BcDHKIs8C5SjCh3jkPcP3HDrlQfJLnAmVcXmUQVumcM/NIcMlzbYUQ37 9wWf5MDEFrl1R+MkIGTYi4DSPZAQK1RRsL06a3s5OeOMohFSaGEii6PVaTNT1IkgJUeP R1yQ==
X-Received: by with SMTP id as10mr32245086obc.70.1373562902099; Thu, 11 Jul 2013 10:15:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 11 Jul 2013 10:14:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: James M Snell <>
Date: Thu, 11 Jul 2013 10:14:42 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: Amos Jeffries <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.705, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UxKSm-0003W5-5W 217842347198e8e8becd4f82f82b1dff
Subject: Re: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18697
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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).