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

Andy Green <andy@warmcat.com> Thu, 01 December 2016 03:40 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 B4BB7129441 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 19:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.174
X-Spam-Level:
X-Spam-Status: No, score=-8.174 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, RCVD_IN_DNSWL_HI=-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 (1024-bit key) header.d=warmcat.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 25e934DpjLho for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 19:40:55 -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 4CF0F128874 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 19:40:55 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCIBJ-0003O1-RG for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Dec 2016 03:37:09 +0000
Resent-Date: Thu, 01 Dec 2016 03:37:09 +0000
Resent-Message-Id: <E1cCIBJ-0003O1-RG@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <andy@warmcat.com>) id 1cCIBC-0001v8-KQ for ietf-http-wg@listhub.w3.org; Thu, 01 Dec 2016 03:37:02 +0000
Received: from mail.warmcat.com ([163.172.24.82]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <andy@warmcat.com>) id 1cCIB5-0003Fc-Cv for ietf-http-wg@w3.org; Thu, 01 Dec 2016 03:36:57 +0000
DKIM-Filter: OpenDKIM Filter v2.10.3 warmcat.warmcat.com 23DEBD98B8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=warmcat.com; s=dkim; t=1480563377; bh=GUmq6gfACCwohF77mXCrC0Yjd0J5xiXKId3IwdAmkxc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Jqvl/6gXSnWauFuDDLCpEDc1foGBPMs0Ywv7r1BaR/woxqBx95h7PeIqmPS4wY79f 6rFExDUNueILes9cDrPS1/p5BQtIU/ppP5SZa6iRr2tL7zBS3I0NHGFz+Hi3iFU2gP M6jdBhJn/f3kpv1sZHufzV442QSaVyn1YgAMItXE=
Message-ID: <1480563376.4219.1.camel@warmcat.com>
From: Andy Green <andy@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>
Date: Thu, 01 Dec 2016 11:36:16 +0800
In-Reply-To: <CAG-EYCj6kn=MwAZf9t=pKFChQV=m4jYFXXBhKAy_8GiMe9Vz0g@mail.gmail.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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=163.172.24.82; envelope-from=andy@warmcat.com; helo=mail.warmcat.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=-0.911, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.899, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cCIB5-0003Fc-Cv f68b21cc6ea10d321260cb0df5d84bb8
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/1480563376.4219.1.camel@warmcat.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33058
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>

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