- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 29 Nov 2014 17:26:34 +1300
- To: Andy Green <andy@warmcat.com>, ietf-http-wg@w3.org
-----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-----
Received on Saturday, 29 November 2014 04:27:32 UTC