Re: HTTP/2 and Websockets

Roberto,

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?

On Sat, Nov 29, 2014 at 1:51 PM, Roberto Peon <grmocg@gmail.com> wrote:

> All it needs is a new DATA frame which allows the signaling of
> end-of-message (with a single bit), and a mechanism (HEADERS would do if it
> can be flow controlled on the one stream) to modify metadata
>
> Everything else is there in the protocol already.
>
> -=R
>
> On Fri, Nov 28, 2014 at 8:26 PM, Amos Jeffries <squid3@treenet.co.nz>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 27/11/2014 1:05 p.m., Andy Green wrote:
>> >
>> >
>> > On 26 November 2014 17:03:55 GMT+08:00, Amos Jeffries wrote: On
>> > 26/11/2014 2:43 p.m., Andy Green wrote:
>> >>>>
>> >>>>
>> >>>> On 26 November 2014 09:39:37 GMT+08:00, Yutaka Hirano wrote:
>> >>>>> Sorry that the proposal was updated in another place:
>> >>>>>
>> >
>> https://github.com/yutakahirano/ws-over-http2/blob/master/ws-over-http2-message-mapping.md
>> >>>>>
>> >>>>>
>> >
>> >
>> I forgot to link the document.
>> >>>>>
>> >>>>> In the github document, a WS message is encoded to HEADERS
>> >>>>> + DATAs.
>> >>>>
>> >>>> OK... then I guess we could agree, calling it super
>> >>>> inefficient was being kind ^^
>> >>>>
>> >>>> What we're talking about now, HEADERS to make the upgrade one
>> >>>> time and then pure DATA representing one ws frame, would be
>> >>>> perfect. But I don't know how to get rid of the WS_FLAGS byte
>> >>>> in the payload right now to get there.
>> >>>>
>> >
>> > andy, why are you still talking about "upgrade" ?
>> >
>> >> Because we will indeed be upgrading the default http2 protocol
>> >> for the stream to ws.
>>
>> But the stream does not exist as a HTTP/2 stream until its started as
>> a WS stream. So I think there is a paradigm shift needed in the thinking.
>>
>>
>> >
>> >> So we need to signal to intermediaries that we're changing the
>> >> rules for that stream.
>>
>> Opening a WS stream does that.
>>
>> >
>> >> If the intermediary thinks... "oho... I don't think so" then he
>> >> can NAK the upgrade right there and avoid a nasty situation the
>> >> endpoints wrote a cheque that the intermediaries cannot cash.
>> >
>>
>> If the intermediary advertised WS support in its SETTINGS previously
>> then it has already guaranteed that it will understand and properly
>> handle the WS streams.
>>
>> So...
>>
>> >
>> > moving the entire underlying protocol connection from HTTP/1 to WS
>> > was a HTTP/1 artifact that should no longer be necessary at all in
>> > HTTP/2. Just open a new WS-type stream to a peer advertising WS
>> > support and presto it contains WS protocol.
>> >
>>
>>
>> Overall I am thinking that WS just needs 1) a WSHEADERS frame type to
>> initiate WS streams, and 2) a SETTINGS parameter to advertise support
>> for WSHEADERS streams.
>>  DATA contains payload for the stream either WS or h2. Both handled in
>> the same way by intermediaries.
>>
>> Amos
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBAgAGBQJUeUr6AAoJELJo5wb/XPRjvxoH/2VG9f7uN+VZM2LJAghbEDK3
>> nEUoptPw4TIG/nt2LgBWU8qCnL+kNfVzfSWSEdw2FFI9XdS3T99eAAWXBEJcHsE6
>> Vf2AxpoassRYXr13p2Tmjo6Lz0/uLhoFgNYePGdSEyKS75tULaoQP0rM05H3w3Ym
>> EWPvn4vtFkmWgRm/39lMvGBZjvnTlaKBEIl8rrSRE2BUDAbfSBzcr/2V8ZOpPHm+
>> DnetSTFP2UpLRu1Ufsir4bnTh3vhf6810HBTz5ylO8rUYIuqkGJwLuGmjSIE2V3z
>> uB/tVxr7903nw6o4/FtwGwvJKXt8QJujEswdEan2SoQhBkJaO+tfBaq4hyO3Wc0=
>> =WW/v
>> -----END PGP SIGNATURE-----
>>
>>
>