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

Re: Call for Consensus: Frame size (to address #553)

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Mon, 14 Jul 2014 17:46:58 -0400
Message-ID: <CAEn92TrJz8E8kCiXzcVCft2gGhQpHN6i3PYdU4TMyPcv3D1=PQ@mail.gmail.com>
To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Yoav Nir <ynir.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> I opened this very issue a few weeks ago.  I was told that if you set the
> table size to 0, you can rst_stream, but you don't have to close the
> connection. When the client retries it should have already seen your new
> settings with table_size=0 and max_frame=256, so all should be well.

This is true, you're correct. I do still think that requiring deployers of
HTTP/2 to be so intimately aware of the relationship b/w max frame size,
hpack table size, and sizes of compressed header sets sent from clients is
a bad idea, and wholly unnecessary.

> I'm not that interested in talking about lightbulbs. These use cases can
> appropriately be covered by h2-lowprofile / h2-c, and I've no objection to
> a 256 byte default and minimum in that context.
> +1 for different profiles
> But unfortunately as of today, no such profile(s) exist.  Roberto (and
> somebody else?) wrote a draft that suggested different profiles, but it
> didn't gain much traction.  I brought it up again several weeks ago, but
> all I heard was crickets.

Speaking personally, I don't understand the use cases well enough. A
low-profile mode which uses base HTTP/2 framing but changes initial
settings makes plenty of sense to me. I don't understand well enough what
those limits ought to be, and am happy to let those who do drive that
Received on Monday, 14 July 2014 21:47:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC