Re: Striving for Compromise (Consensus?)

On 11 July 2014 23:18, Jeff Pinner <> wrote:

> > I'm with Greg, though, what is the reason for needing a distinction
> between HEADERS and DATA frames?  The same thing could easily be
> accomplished with just DATA frames logically divided into a http request of
> "headers data [trailers]" just by the END_SEGMENT flag.
> The distinction is due to two things:
> 1) Having different opcodes for DATA and HEADERS frames allows us to
> know up front if the frame needs to be decompressed by HPACK.

Well firstly the framing layer shouldn't have to know how the contents of
the frame need to be processed.  That is higher layer business.    It is
only because we have built in stateful HTTP header compression into the
framing layer that this is required information.

But it would be known anyway.  It is not hard to say that the first data
segment of a HTTP stream contains headers.

But hey, I can accept calling them HEADERS instead of DATA, so long as we
have the same fragmentation mechanism rather than a different one.

> 2) Unlike DATA frames, HEADERS contain content that is not arbitrarily
> divisible which makes flow controlling them difficult
> "out-of-the-box."

Again this is only because of the conflation of layers.   Data cannot be
arbitrarily split either when considering its semantic meaning.  It is only
because the reassembly occurs before the data is interpreted that we can
fragment data.  So its easy, lets kick HEADER decoding out of the framing
layer and then decoding headers is just the same as decoding XML data as
far as fragmentation is concerned.

Besides, I don't think there is any requirement currently to split a
HeaderBlock into Header Block Fragments on a field boundary.  In fact the
spec allows for an individual field to be of arbitrary size, so one field
may cross several frames.


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Saturday, 12 July 2014 06:06:46 UTC