Re: h2 priority

On 1 September 2014 09:06, Roy T. Fielding <fielding@gbiv.com> wrote:

> YIKES!  I already mentioned padding in a prior message, so let's just
> assume that has been deleted.
>

and if your END_STREAM proposal is accepted then all we are left with in a
HEADERS frame is

   Header Block Fragment

making this frame identical to CONTINUATION frame.    No need for both.

Further,  if we had restored the END_SEGMENT semantic, then we could use
that instead of the END_HEADERs flag and HEADERS frames would become
identical to DATA frames.

For HTTP semantics, we would simply define (in a layer above framing) that
the first segment is headers, the second data and the optional 3rd is a
trailer.  For websocket semantics, the END_SEGMENT could denote message
boundaries within a stream

We would then have a moderately generic framing layer capable of carry
multiple semantics without the need to revisit the framing layer
implementation for every extension or new protocol.    We would have to
refine hpack a little bit more, but then header compression should never
have been a concern for the framing layer in the first place!

Sorry to keep pushing the same barrow, but I think the current draft has
landed on a local minima of a self consistent design.  Change almost
anything and you pop it out of the local minima and a lot more design
decision will not longer make sense.

cheer








-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.