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

Re: CONTINUATION was: #540: "jumbo" frames

From: Jason Greene <jason.greene@redhat.com>
Date: Fri, 27 Jun 2014 14:34:05 -0500
Cc: Greg Wilkins <gregw@intalio.com>, Roberto Peon <grmocg@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <580D6E01-A721-4B78-B5B9-2ED91F15FBD4@redhat.com>
To: Cory Benfield <cory@lukasa.co.uk>

On Jun 27, 2014, at 3:05 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

> I'm less delighted about muxable (i.e. HPACK-free) CONTINUATION
> frames, though they might be a better middle-ground solution.
> Implementing them intelligently is a bit awkward and requires a
> substantial amount of care from the emitting party. It also lays traps
> for the unwary such that a single large HTTP header can affect the
> compressibility of several following requests. Careful language in the
> RFC might be able to get around this point.

It can’t affect the compressibility of subsequent requests because the large headers would be in the “uncompressed” frames[1]. Only the first HEADERS frame impacts the delta compression state.

[1] Uncompressed frames can actually still be compressed with HPACK with an effective table size of 0 for those frame if so desired.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Friday, 27 June 2014 19:34:46 UTC

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