Re: HTTP/2 and Websockets

The purpose of the proposal to indicate messages was to ensure that
intermediaries could do balancing and reliability things, and not have to
leave it to endpoints alone, which leads to more latency and heartache.

I liked the idea that one could buy a box from whatever loadbalancer vendor
and it would just work with your traffic with a simple configuration
regardless of the kind of protocol (websocket, rpc-foo, whatever) being
sent over HTTP2 since the message and stream boundaries were all delimited.
-=R

On Wed, Dec 3, 2014 at 7:31 PM, Glen Knowles <gknowles@ieee.org> wrote:

> I've been getting slowly less and less interested in any message
> framing/metadata etc that isn't already in http2. All of my server to
> server or rich client to server use cases would be satisfied at least as
> well by a bidirectional http2 mode as by any websocket proposal I've seen
> so far.
>
>
> On Wed, Dec 3, 2014 at 7:05 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> If headers/metadata isn't flow controlled, then it becomes possible to
>> create an infinite queue on a proxy, e.g. infinite zero-length messages.
>> If one wishes for an ability for a receiver to stop receiving messages,
>> then the headers themselves need to be flow controlled.
>>
>> One way of accomplishing it, which I tried to allude to ( =] ) was that a
>> headers-like-frame which was guaranteed not to use stateful opcodes could
>> be serialized as data (i.e. subject to flow control).
>> Another way of accomplishing it is to have every message require at least
>> a byte of data.
>>
>> -=R
>>
>> On Wed, Dec 3, 2014 at 9:18 AM, Brad Fitzpatrick <brad@danga.com> wrote:
>>
>>> Roberto, what's the motivation for flow-controlled headers? If every WS
>>> message's DATA frame(s) is preceded by a HEADERS to say whether it's JSON
>>> or binary, and DATA are flow controlled, doesn't that mean there's at most
>>> one HEADERS that sneaks by without flow controlled when the peer wants the
>>> other to stop sending? Is it that one small-ish header (the one saying
>>> "next is text" or "next is binary") that concerns you?
>>>
>>>
>>> On Wed, Dec 3, 2014 at 9:00 AM, Roberto Peon <grmocg@gmail.com> wrote:
>>>
>>>> Basically one either needs flow controlled headers, or needs a headers
>>>> frame (or equivalent) which doesn't use a compression context, plus a
>>>> dataframe which can signal end-of-message, at which point we have
>>>> everything one could conceivably need for a message based protocol.
>>>>
>>>> -=R
>>>> On Dec 3, 2014 8:17 AM, "Martin Thomson" <martin.thomson@gmail.com>
>>>> wrote:
>>>>
>>>>> On 3 December 2014 at 07:49, Yutaka Hirano <yhirano@google.com> wrote:
>>>>> >> a mechanism (HEADERS would do if it can be flow controlled on the
>>>>> one
>>>>> >> stream) to modify metadata
>>>>> >
>>>>> > Sorry I'm not sure what it means: Can you explain?
>>>>>
>>>>> HEADERS
>>>>> Subsequent-Frames-Will-Be: binary
>>>>> Other-WebSockets-Meta-Information: here
>>>>> DATA...
>>>>> binary frame data
>>>>> HEADERS
>>>>> Subsequent-Frames-Will-Be: text
>>>>> DATA...
>>>>> text frames
>>>>>
>>>>> Roberto wants HEADERS (other than the first) to be flow controlled,
>>>>> but that isn't entirely relevant here.
>>>>>
>>>>
>>>
>>
>