- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Thu, 1 Dec 2016 16:36:36 +0900
- To: Andy Green <andy@warmcat.com>, Van Catha <vans554@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>
- CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Takeshi Yoshino <tyoshino@google.com>, Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Wenbo Zhu <wenboz@google.com>, Martin Thomson <martin.thomson@gmail.com>
On 2016/12/01 12:36, Andy Green wrote: > On Wed, 2016-11-30 at 22:06 -0500, Van Catha wrote: >> see more success. The reason for this is both protocols (HTTP2 and >> QUIC) have their own way of trammiting data frames. Websocket in >> this case should become an alternative frame type, basically one >> carrying a binary payload. All the previous baggage of websocket1 >> can be dropped like the distinction between text/binary frames as > > The logical ws implemention in JS needs that distinction to be carried > over the link though, as it lets you choose and TEXT differs on the > other end by enforcing only valid UTF-8 in the message. So that's not > a ws 1 wire-implementation-only type thing that can just be binned. Yes indeed. Even if it could be binned, it shouldn't. The distinction between TEXT (UTF-8 only!) and BINARY may be of no concern at all to the transport infrastructure, but it is essential for the next layer above. Without this distinction, the risk that JS code monkeys get the conversion from text to binary and back wrong is just way too high. Even just not having to do the conversion by hand is very helpful, and having the character encoding nailed down makes different servers and clients much more interoperable. Regards, Martin.
Received on Thursday, 1 December 2016 07:37:16 UTC