W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

From: Andy Green <andy@warmcat.com>
Date: Thu, 01 Dec 2016 11:36:16 +0800
Message-ID: <1480563376.4219.1.camel@warmcat.com>
To: 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 Wed, 2016-11-30 at 22:06 -0500, Van Catha wrote:
> > HTTP/2 makes many of the pre-WebSocket solutions to this problem
> space much cheaper.  QUIC will probably make it even more so. 
> > If there are people who feel strongly that WebSockets still meet a
> need over a modern HTTP, I'm happy to read and occasionally comment, 
> > but I don't feel called to be integral to that work.
> 
> At this point I wonder if there is a need for a separate solution. 
> Making websockets go over HTTP2 seems to bring up the bureaucratic
> problems of the past.  If websocket can be its own thing, then have
> an implementation for HTTP2 and another one for QUIC, I think it can 

Yeah.

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

> well as ping/pong and close. So we end up with just 1 frame type.
> 
> Compression would be left up to the client js / server code.  The
> websocket2 would be a super simple two way binary stream.
> 
> This is pretty self explanatory, the major problem is how you do
> handle authentication now.  

Negotiating (or asserting) the ws protocol to interpret the message
with is also still needed, again that is a logical ws thing in JS ws
api (and is useful).  Atm in ws 1 initing the ws link in The Real World
looks like this

 - tcp connection establishment

 - GET some html with js

 - 200 comes back with payload

 - js gets to execute

 - tcp connection establishment

 - JS sends an UPGRADE with protocols

 - 101 comes back with agreed protocol

 - you can send ws now

It's two tcp connections (browsers don't pipeline the UPGRADE because
it changes the connection type) and two roundtrips.

HTTP/2 would remove the second tcp connection establishment, and you
could also replace the next two UPGRADE / negotiation steps with an
HTTP/2 new stream open.  The server can send the client a list of ws
protocols it supports when the http/2 link was created.  The client
then just asserts the ws protocol being used as the first thing you
send on the newly opened stream, all being well it continues or if
invalid the stream is killed by the server.

That saves a tcp connection establishment and a roundtrip compared to
http/1 ws...

-Andy

> On Wed, Nov 30, 2016 at 2:29 PM, Mike Bishop
> <Michael.Bishop@microsoft.com> wrote:
> > QUIC's charter doesn't have anything directly to do with
> > WebSockets.  But I agree that since WebSockets came from a
> > different WG, it might be a reasonable question to the ADs whether
> > that working group should be rechartered to do an HTTP/2 or
> > HTTP/QUIC port.
> > 
> > HTTP/2 makes many of the pre-WebSocket solutions to this problem
> > space much cheaper.  QUIC will probably make it even more so.  If
> > there are people who feel strongly that WebSockets still meet a
> > need over a modern HTTP, I'm happy to read and occasionally
> > comment, but I don't feel called to be integral to that work.
> > 
> > -----Original Message-----
> > From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk]
> > Sent: Sunday, November 27, 2016 1:19 PM
> > To: Van Catha <vans554@gmail.com>
> > Cc: Mark Nottingham <mnot@mnot.net>; Takeshi Yoshino <tyoshino@goog
> > le.com>; Willy Tarreau <w@1wt.eu>; Andy Green <andy@warmcat.com>; i
> > etf-http-wg@w3.org Group <ietf-http-wg@w3.org>; Wenbo Zhu <wenboz@g
> > oogle.com>; Martin Thomson <martin.thomson@gmail.com>
> > Subject: Re: WiSH: A General Purpose Message Framing over Byte-
> > Stream Oriented Wire Protocols (HTTP)
> > 
> > --------
> > In message <CAG-EYCiVExcyHLoXB1ixQCKduxUPTVOnVX1XrmFJ3b72Y8AAFg@mai
> > l.gmail.com>
> > , Van Catha writes:
> > 
> > >So can we form a new WG then and focus on doing this right vs
> > making
> > >WebSocket2.  The focus earlier was to get the already coded
> > clients and
> > >API (websocket API) to be able to work with websockets layered on
> > >HTTP2/QUIC, if we are in it for the long haul now we might as well
> > form
> > >a new group and create something more long term?
> > 
> > Apologies for asking a stupid question, but isn't that exactly what
> > QUIC is all about in the first place ?
> > 
> > --
> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> > phk@FreeBSD.ORG         | TCP/IP since RFC 956
> > FreeBSD committer       | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by
> > incompetence.
> > 
> > 
> 
> 
Received on Thursday, 1 December 2016 03:37:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 December 2016 03:37:05 UTC