Re: #537: Remove segments (consensus call)

I worry we'll regret losing segments and mid-stream HEADERS (or METADATA or
the like).

The hop-by-hop HTTP use-cases (eg, in ICAP and for data integrity
protection) seem like one where we can re-introduce them fine with
extensions.  However the end-to-end cases (WebSockets) seem like they will
be harder to get intermediates to support well in the long-term if we don't
define them now.

Similarly, when WebSockets and the like do implement something, the
would presumably be much more consistent if the framing layer has a clearly
mechanism for supporting them so that each one of them doesn't result in a
slightly different frame type with slightly different formatting and


On Tue, Jul 15, 2014 at 11:15 PM, Roberto Peon <> wrote:

> I'd say that the current stance is that anything which isn't part of the
> past set of usecases for http will not be considered for h2.
> This is disappointing, but there it is. It is difficult to do anything
> forward looking in committee, regardless of its venue or the talent of its
> members.
> On Jul 15, 2014 6:55 PM, "Yutaka Hirano" <> wrote:
>> I'm a bit behind, can you tell me what you mean by "semantic-free"
>> It the current stance for extensions (such as WebSocket) "Do not abuse
>> HTTP related frames. Instead, define and use extension-specific frames"?
>> On Wed, Jul 16, 2014 at 8:57 AM, Greg Wilkins <> wrote:
>>> On 16 July 2014 09:46, Martin Thomson <> wrote:
>>>> You can try to start h2 and then upgrade to websockets if the ALPN
>>>> negotiation selects http1.1.
>>> Currently this kind if decision is made above the browser in javascript
>>> libraries that have to decide if they are going to use websocket or long
>>> polling.  If they use long polling, for h1 they have to be aware of
>>> connection limits and currently some assume 2, while others have been
>>> updated to 6.  A much higher connection==stream limit will need to be
>>> applied if long polling over h2.     But these frameworks don't have the
>>> ability to take part in h2/upgrade negotiations and any knowledge they get
>>> about protocol versions will be late.  They probably don't have access to
>>> max stream settings, so will be guessing again.
>>> Now if h2 had supported websocket semantics from day 1, then these
>>> libraries could have just handed over the messages to the browser and it
>>> would be up to the browser to work out the best way to transport.
>>> Anyway.... I've made my point (several times) that I think it was a
>>> mistake for the charter to not support all the current web semantics.  I
>>> guess that horse bolted a long time ago.
>>> cheers
>>> --
>>> Greg Wilkins <>
>>> HTTP, SPDY, Websocket server and client that
>>> scales
>>>  advice and support for jetty and cometd.

Received on Wednesday, 16 July 2014 21:53:29 UTC