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

On Wed, 2016-11-30 at 23:03 -0500, Van Catha wrote:
> > 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.
> 
> You are in control of the server and client.  Why can you not just 

That is not always the case.  For example we have a user using IBM's
Watson Test-to-Speech cloud service

https://www.ibm.com/watson/developercloud/doc/text-to-speech/websockets
.shtml

He is in control of the client, but he's just another consumer of IBM's
ws protocol.  I guess there are an increasing number of examples of
this that the server is somebody's service and there are independent
clients that may connect to it using the published protocol.

> cast from ArrayBuffer to String (on js side) if you know both your
> client and server are sending strings.  Its an unnecessary burden to
> have both text and binary frames, its also unnecessarily confusing.

I see your point, but it's in the JS ws api implemented in the
browsers.  It's desirable that should work as much the same as possible
regardless of the transport.  Some other guys decided the JS api.

> The problem is UPGRADE got dropped in HTTP2. The only reasonable
> option lefts seems to be Alt-Svc.  ws-quic, ws-http2 Alt-Svc can
> become a thing perhaps.  The requirement of sending browser headers
> (HTTP2) becomes difficult to reasonably handle.  Maybe it can work by
> opening the new stream then the first message Websocket will send is
> the headers as if it was a normal request (over the ws channel).  

But we have to keep the negotiation roundtrip then.  Originally a major
thought for ws 1 UPGRADE was to confirm nonsupporting servers would
choke on it and fail the connection, hence the required hash
computation thing on both sides.  So they accepted early there would be
http headers and a roundtrip opening a ws connection.

Aside from ws protocol negotiation it also lets the ws connection have
a URL space, and the client to send cookies.

I think you can maybe just assert those things that are necessary from
the client, like URL path, cookies and ws protocol, when you open the
ws stream.  If the server is happy, it accepts and processes traffic on
the stream, which may be pipelined.  If not it kills the stream before
processing anything.

> We do not have anything in HTTP2 to handle an UPGRADE currently.  If
> the websocket stream is opened first (client made aware through Alt-
> Svc), well we've already upgraded!

Yes but if we can signal it is a "ws stream" when the stream is opened,
actually the concept of UPGRADE and its roundtrip can maybe be
eliminated in favour of the client just asserting things that either
fly with the server or gets the stream killed.

About auth, usually the browser has authenticated to get to the html +
scripts to make the ws connection that needs auth.  Maybe the ws stream
can be a logical child of that and share any cookies the parent has
that are operable on the ws URL path.

-Andy

> 
> 
> 
> 
> 
> On Wed, Nov 30, 2016 at 10:36 PM, Andy Green <andy@warmcat.com>
> wrote:
> > 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 <wenb
> > oz@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 04:51:38 UTC