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

Re: Large Frame Proposal

From: Jason Greene <jason.greene@redhat.com>
Date: Tue, 8 Jul 2014 22:29:04 -0500
Cc: (wrong string) 陈智昌)" <willchan@chromium.org>, Mike Belshe <mike@belshe.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <ABC278AA-D736-4693-9C64-DFC4D329A806@redhat.com>
To: Jeff Pinner <jpinner@twitter.com>

On Jul 8, 2014, at 10:20 PM, Jeff Pinner <jpinner@twitter.com> wrote:

>> Hey Jeff,
>> How is this different to you from dynamically adjusting the header table size?
> I see it differently because the compressor (at least in my
> implementation and so I realize I definitely could be biased) lives
> above the framing codec. The low-level framer emits "header block
> fragments" to the session processing code which then emits "header
> fields" to the application.

Ok so, what you dont like then is your framing layer having to inspect a settings frame? 

If so, dont you also have the same issue with extensions? Although I guess a key difference there is they are once per connection.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Wednesday, 9 July 2014 03:29:43 UTC

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