- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 27 Jun 2014 14:34:05 -0500
- To: Cory Benfield <cory@lukasa.co.uk>
- 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>
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