Re: HTTP/2 and Websockets

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