W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HEADERS and flow control

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 22 May 2014 03:49:01 -0700
Message-ID: <CABkgnnWfrie7Fg9_pXM=ny5cefQrQg+SJKBYoTRpdtyv9yyg_w@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>
On May 22, 2014 12:04 AM, "David Krauss" <potswa@gmail.com> wrote:
> We can nip this all in the bud by limiting header block size. For
header-heavy protocols, dividing the metadata stream into multiple blocks
should be an essential feature in any case. Should an upper limit be set on
header block size? How could it be specified?

We have asked before about setting a hard limit. That doesn't work. There
are too many existing uses and users that wouldn't be able to use HTTP/2 as
a result.

A declared maximum (i.e., settings) might work.

You can't however reject a header block that you don't want. Not without
also dumping the connection. Common state being what it is.

The best approach is to stream headers. The HPACK design permits it, and
that allows for a bounded state commitment. The only real cost is the head
of line blocking.

> Note, Huffman “compressed” binary data is 3.5x bigger on the wire, so 1
MiB decoded is up to 3.5 MiB transferred. I might be guessing high by many
orders of magnitude, but I’m just being conservative on the side of the
currently apparent design intent, which is to be unlimited.

That is perhaps true if you do the naive thing, and only if you don't have
any syntax constraints. The real cost depends, but if you do cookie syntax,
it's closer to 1.6.
Received on Thursday, 22 May 2014 10:49:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC