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

Van Catha <vans554@gmail.com> Thu, 01 December 2016 04:07 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560DE128874 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 20:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.673
X-Spam-Level:
X-Spam-Status: No, score=-7.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjDVyZb8okCl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 20:07:40 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D392129630 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 20:07:40 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCIbU-0002I9-T3 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Dec 2016 04:04:12 +0000
Resent-Date: Thu, 01 Dec 2016 04:04:12 +0000
Resent-Message-Id: <E1cCIbU-0002I9-T3@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1cCIbI-0002HG-Ci for ietf-http-wg@listhub.w3.org; Thu, 01 Dec 2016 04:04:00 +0000
Received: from mail-qt0-f173.google.com ([209.85.216.173]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <vans554@gmail.com>) id 1cCIbA-0006r6-Em for ietf-http-wg@w3.org; Thu, 01 Dec 2016 04:03:55 +0000
Received: by mail-qt0-f173.google.com with SMTP id n6so209481987qtd.1 for <ietf-http-wg@w3.org>; Wed, 30 Nov 2016 20:03:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2lNXSCbzw7uupC7e6jlOqqWrLocEXo/y863Cxe0wOpw=; b=p+w3fe+PT89lmH/+AndV8rXZKcw5JL9No715B9HPTmPlQEsn/kFvBBv2XdxEph/E2d i6UTw/dLOQDQQ0TG8z7oRCCmrjgdK0quky/MSrd8zgnquXjne/DR0GqBMmwReDCjcK70 x58H+YGt1eEzRDwbVjSPyRcc1db91urE6Y8htoLCrPbR3WbSdjKC2rHc1kGqOUzCM8SQ /kGKXCCL62VBFXQduUxjMAGbLdRI5OhRYHdPD8HVAAm4qPrQ5ZlpOavbEWIwWt3c4QXS hiY0bIKUKMKxX3RUj1A3AkQetFU4iudGB5kXqwDV3sdFogqT4heUjyvGii0irt/mkfpi hR7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2lNXSCbzw7uupC7e6jlOqqWrLocEXo/y863Cxe0wOpw=; b=b2Tae8QEu8c/zwQCpFh0xDAapJWyecGezF5n79PgsLxr81gnn6jhhKEuaogbSZ2u9p cqViDU2UGfG0h8/nig85b5NJth0i0GIZdbZL4w9J7kWu96NMLwPHMq96bRDeLOE+GRoW cdy2f+dvdl12mcn18DbjOaIkjr9gAxMvpVis3CrOuXszBWw8EE0V5BTJ241PyAEEfLVn ofr+YsfCzLOih5bu6RlGtU1yGcvY+5iGKFODD6TlTB0PHdPnvmVjWH0/V4Sz1FFCoF6G 8d8Dwe3KssTa2K0gysc8VUqkj0CS/StC4ik/WxrUWON4stId+Bav+hyllX6yH2EvKHDA e4gQ==
X-Gm-Message-State: AKaTC02ydl88mMgHJ4yzyp71yS1gTJOjcaPa+ao3/SsVzt91SBwbEFqGYLrRUFV8EhXgIjUutKOVtQi2wZvIzQ==
X-Received: by 10.237.33.156 with SMTP id l28mr35794425qtc.111.1480565005750; Wed, 30 Nov 2016 20:03:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.209.8 with HTTP; Wed, 30 Nov 2016 20:03:25 -0800 (PST)
In-Reply-To: <1480563376.4219.1.camel@warmcat.com>
References: <CAH9hSJZB0SyFiqLqLjd9R-T11yTa12Ekb-H8hYwfc6FeOjD2xQ@mail.gmail.com> <CAP8-FqmU+uBas5zH8oQHkt0zh18YrBm-O-umGPGMkLAjShw1Gw@mail.gmail.com> <CAH9hSJa10DLSozTpXjETyFX0bVYqfRbRFJnmFQNRGeSuZVKWPQ@mail.gmail.com> <CAG-EYChszHdWhp=o+fdOW+pAN90t61MExzsLnteM3tmf9=N0Yw@mail.gmail.com> <CAH9hSJbNk83FT0WqB1tHJvEfaU5CMoAaKRdvy8NTb4zgEUdzBw@mail.gmail.com> <CAG-EYCjwptZcsHeDKwyRBhLTREEC4zxXxtTZvNLe2m1ei2r55g@mail.gmail.com> <437A6E14-03A9-42DD-A4B8-921C80EC5729@mnot.net> <1480035079.3044.1.camel@warmcat.com> <8E039C1D-A9B6-40E4-937E-A55D327FBDC5@mnot.net> <1480041123.3044.3.camel@warmcat.com> <20161125065208.GB4488@1wt.eu> <CAH9hSJacZp4LqAp61yCTsVqSeomSc5aZfTFjQUfbmHrOqr3VGg@mail.gmail.com> <DCFCC7B0-717E-496A-8B4D-C409A1B965F0@mnot.net> <CAG-EYCiVExcyHLoXB1ixQCKduxUPTVOnVX1XrmFJ3b72Y8AAFg@mail.gmail.com> <68448.1480281530@critter.freebsd.dk> <BN6PR03MB2708FEE0880AB9BDB1B4778B878C0@BN6PR03MB2708.namprd03.prod.outlook.com> <CAG-EYCj6kn=MwAZf9t=pKFChQV=m4jYFXXBhKAy_8GiMe9Vz0g@mail.gmail.com> <1480563376.4219.1.camel@warmcat.com>
From: Van Catha <vans554@gmail.com>
Date: Wed, 30 Nov 2016 23:03:25 -0500
Message-ID: <CAG-EYCjHmHR6z8hqqnUUCf7KtD4jOrcXNbQnPJDiiMijvqp=gQ@mail.gmail.com>
To: Andy Green <andy@warmcat.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, 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>
Content-Type: multipart/alternative; boundary=001a11397c543c16cc054290e79d
Received-SPF: pass client-ip=209.85.216.173; envelope-from=vans554@gmail.com; helo=mail-qt0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-1.992, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cCIbA-0006r6-Em e1cd6bf2ffd2e013aa676429e9e52101
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <http://www.w3.org/mid/CAG-EYCjHmHR6z8hqqnUUCf7KtD4jOrcXNbQnPJDiiMijvqp=gQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33060
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> 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 <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>et>; Takeshi Yoshino <tyoshino@goog
> > > le.com>; Willy Tarreau <w@1wt.eu>eu>; Andy Green <andy@warmcat.com>om>; i
> > > etf-http-wg@w3.org Group <ietf-http-wg@w3.org>rg>; 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.
> > >
> > >
> >
> >
>