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

Re: #540: "jumbo" frames

From: Jason Greene <jason.greene@redhat.com>
Date: Wed, 25 Jun 2014 21:14:42 -0500
Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <31498D41-244F-40F5-8FC5-BB8A13EF408D@redhat.com>
To: Matthew Kerwin <matthew@kerwin.net.au>

On Jun 25, 2014, at 6:53 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> On 26/06/2014, Greg Wilkins <gregw@intalio.com> wrote:
>> Continuations are jumbo frames!  They are just really bad jumbo frames that
>> only apply to headers, can't be efficiently handled and don't have a
>> mechanism for end points to pre declare max acceptable sizes.   General
>> jumbo frames would handle the headers use-case, but also provide a solution
>> for those who need efficient large data.
> Data is a single unit, with simple properties for concatenation, so
> it's trivial to split into multiple frames at one end and recombine at
> the other.
> The equivalent metadata unit is the header block, but that doesn't
> have the same recombination properties; so while it can be split into
> multiple frames, there are rules about streaming and interleaving.
> Those rules result partly from the record-based nature of the
> underlying headers, but mostly from the shared state. To eliminate the
> shared state issue I see a couple of options:
> 1) allow multiple header blocks to be sent on one stream, and remove
> continuations. Interleaving wouldn't be a problem, but it wouldn't be
> possible to send large individual headers. More kluge required.
> 1.5) Only compress the HEADERS, make CONTINUATIONs stateless. Pros and
> cons as above.

This option could still support large headers in the uncompressed CONTINUATION frames.

I was just thinking perhaps HEADERS w/ CONTINUATION should require a total multi-frame length? 

One of the biggest problems with CONTINUATION is that a server has no idea how huge the headers will be, and is forced to buffer them until a limit is hit. If this information was known up front it could either RST_STREAM, or simply discard all subsequent CONTINUATION frames and reply with a too large status. 

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Thursday, 26 June 2014 02:15:25 UTC

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