Re: HTTP/2 and Websockets

On Wed, Dec 3, 2014 at 7:38 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
>>
>
Started a short survey doc on this general topic.
http://www.ietf.org/mail-archive/web/hybi/current/msg10580.html

Comments welcome, to hybi or here.



>
>>
>> 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.
>>>>>>
>>>>>
>>>>
>>>
>>
>