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

[Van Catha <[e-mail]>]

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

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

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!






On Wed, Nov 30, 2016 at 10:36 PM, Andy Green <[e-mail]> 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
> > <[e-mail]> 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:[e-mail]]
> > > Sent: Sunday, November 27, 2016 1:19 PM
> > > To: Van Catha <[e-mail]>
> > > Cc: Mark Nottingham <[e-mail]>; Takeshi Yoshino <tyoshino@goog
> > > le.com>; Willy Tarreau <[e-mail]>; Andy Green <[e-mail]>; i
> > > [e-mail] Group <[e-mail]>; Wenbo Zhu <wenboz@g
> > > oogle.com>; Martin Thomson <[e-mail]>
> > > 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
> > > [e-mail]         | TCP/IP since RFC 956
> > > FreeBSD committer       | BSD since 4.3-tahoe
> > > Never attribute to malice what can adequately be explained by
> > > incompetence.
> > >
> > >
> >
> >
>