Re: HTTP/2 and Websockets

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