Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Martin Thomson <martin.thomson@gmail.com> Thu, 26 October 2017 23:07 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A670313A296 for <hybi@ietfa.amsl.com>; Thu, 26 Oct 2017 16:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 wBX65Zl0ZcJ5 for <hybi@ietfa.amsl.com>; Thu, 26 Oct 2017 16:07:34 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD5B139F44 for <hybi@ietf.org>; Thu, 26 Oct 2017 16:07:34 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id a132so8317933oih.11 for <hybi@ietf.org>; Thu, 26 Oct 2017 16:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2u0x3whVd70qSnIZ8X0MAjsQiOS6wf2XKEjuHLqP4uk=; b=Pryrq1g/0mr+K4PLppLw+YuxJC2Rt3daK5hDVtZz8pnZPXN3SfZw12GFy+9uUluBpw m7gIAyi0XrLhF06JKaJqmdHqmcbLTXIdEO77x48LbXD9SWxjqKTnN0APF5kA3mwzmjrb fnHkztEVn3QuxCvBeK/u8foEsnn9fLyRc2dQZmIDXrzGbU8cZbzkjWLwQLEjpHwaj3yI hImqTfAZOjI0WkUnIbh4n4MoU8e5QYBG4uBfMgIPVho3MFXcfXxILzf+8fZ0G+SKIjnF BBURs8aHeEnWGfUwn5l5Wu3CTRmflTdqi8+pmE3BkifNk4izaV5aB5jdk9+aO7P9F47Z Nq7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2u0x3whVd70qSnIZ8X0MAjsQiOS6wf2XKEjuHLqP4uk=; b=WO9ibgd/EsWIWUm+PNN3+BobgVYQlotm3VTfzqyO9oOpDIQ5LNO6xAnPBJQy7iUEbi hxPnn6SoWls8igdd8fNa124FBUeKY23/8AI92XTukR0JlkIXZ6bkF1psul2AIUJY4A4q BdYVr/7rB5ag/EOwsy4SwSOwAntTlunFNiNy21qbvUGHgHUA+E15NgbxcoQnUzAIVzY5 ABcYL/DNJLGIFPUQADAVxyb//aHHUhDYh06bNxDGAUxXoE08/0l4tNTnUe+UwYD/es7T eX2JcUzQV5EFqU2nR1KpMk1LkrQ9opUgnQvCdDoHKfUxIWPBALGmliCGz9yHnIelDIBc 0q/Q==
X-Gm-Message-State: AMCzsaWT9evwJEoeice4+wlB1Z/IJoZn90/Xe8ccJk1NXrFixh4sBxic kLP8qxqscld2duZhJtMb+YXyT3KicU6CNyu3Gtc=
X-Google-Smtp-Source: ABhQp+RDoJfWZcL84R1NDen3O3F9bY0UPYYzwE6F5IhC5eNQiyJuHdqOPZfTVlaosaanyNkPT5KidGt17itsebbF8qM=
X-Received: by 10.202.213.209 with SMTP id m200mr3107969oig.177.1509059252664; Thu, 26 Oct 2017 16:07:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.72.178 with HTTP; Thu, 26 Oct 2017 16:07:32 -0700 (PDT)
In-Reply-To: <CACAJL3nEB5jGFXpqPZ2ErdkezCHpZE1CnqXy0yomBP-v7jcGRA@mail.gmail.com>
References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> <CAOdDvNrC1PgribOiDc93hfCDFSJbjodnU8=yeNWgzkq4Cm-2Cg@mail.gmail.com> <CACAJL3nEB5jGFXpqPZ2ErdkezCHpZE1CnqXy0yomBP-v7jcGRA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 27 Oct 2017 10:07:32 +1100
Message-ID: <CABkgnnVnotgrOBE2o=mi7BxvLEK3MGt_Rr3vmwnLtZ=5VpaOow@mail.gmail.com>
To: John Fallows <john.fallows@kaazing.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a113de3acb3425f055c7b3c50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/_Gutf_Gmt7n1gdelVB0D2841nZ4>
Subject: Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Oct 2017 23:07:37 -0000

I think that John is right here.  Packing the websocket handshake into DATA
frames is more complicated than just using the headers.  The main
difference then between this handshake and the websockets one is:

* it's HTTP/2
* it might use a different method (CONNECT or TUNNEL rather than GET)
* it uses :protocol instead of Upgrade

I still lean toward CONNECT for this, despite reservations about the subtle
difference between usages (proxy vs. origin).  A natural lightweight
implementation of this has the server add proxy code that forwards the
tunnel to a websocket server.  That proxy would need to perform the
old-school 6455 handshake with the websocket server, but could construct
that from the headers of the CONNECT request.  The handling of the header
might be different, but the DATA frames are handled just like a CONNECT
tunnel.  That said, there is enough difference here to justify a different
method.

If you do use CONNECT, then you can define a default for :protocol of "tcp"
so that there is some sort of regularity to the overall structure and
people can build properly generic routing.

One thing that using :protocol suggests to me is that we need a new status
code for this, just in case someone asks for an unsupported protocol.  And
you probably want a registry for :protocol values (yay).



On Fri, Oct 27, 2017 at 8:47 AM, John Fallows <john.fallows@kaazing.com>;
wrote:

> Hi Patrick,
>
> Many thanks for spearheading this latest effort to define WebSocket over
> HTTP/2, it's really encouraging to see the progress.
>
> I recall from the early days of the WebSocket protocol design, probably
> around the time we moved it from W3C HTML5 to IETF HyBi, that the client
> handshake required sending additional content after the GET w/ Upgrade
> HTTP/1.1 request.
>
> This approach led to increased implementation complexity because the
> HTTP/1.1 layer on the server now needed to know how to special case the
> WebSocket usage of GET. It was also a bit trickier than desired because
> that special case processing of GET now spanned over headers and some
> initial content.
>
> Ultimately, that approach was dropped in favor of a single
> request-response to define the WebSocket handshake over HTTP/1.1, with no
> additional request payload needed to process the handshake, making the
> implementation simpler and with better abstraction layering.
>
> The current proposal for WebSocket over HTTP/2 seems to be following a
> similar approach to that described above at the moment, with the HEADERS
> frame (requiring special-case processing of CONNECT) and first DATA frame
> both needed to process the server-side WebSocket handshake over HTTP/2.
>
> Suggest we instead fold the origin and relevant RFC-6455 defined HTTP
> headers into the HEADERS frame for simplicity, recognizing as Mark noted
> that CONNECT is not really intended for use directly at the origin server,
> and instead use a TUNNEL method with corresponding :protocol
> pseudo-header, where the value of the TUNNEL :protocol pseudo-header
> drives the expectation of additional HTTP/2 headers that should be present.
>
> [[ From Client ]]                        [[ From Server ]]
>
>                                             SETTINGS
>                                             ENABLE_TUNNEL_PROTOCOL = 1
>
> HEADERS + END_HEADERS
>    :method = TUNNEL
>    :protocol = websocket
>    :scheme = https
>    :path = /chat
>    :authority = server.example.com:443
>    origin = http://www.example.com
>    sec-websocket-protocol = chat, superchat
>    sec-websocket-version = 13
>
>                                             HEADERS + END_HEADERS
>                                             :status = 200
>                                        sec-websocket-protocol = chat
>
>    DATA
>    WebSocket Frames
>
>                                             DATA + END_STREAM
>                                             WebSocket Frames
>
>    DATA + END_STREAM
>    WebSocket Frames
>
> Note also that the scheme is "https" rather than "wss" because the HTTP
> request is still "https" until *after* the TUNNEL has been established, and
> the TUNNEL protocol being selected is based on :protocol header rather
> than the :scheme header.
>
> Hope this is helpful and interested to hear your thoughts and feedback.
>
> Kind Regards,
> John Fallows
> CTO, Kaazing
>
> On Thu, Oct 26, 2017 at 10:32 AM Patrick McManus <pmcmanus@mozilla.com>;
> wrote:
>
>> This is an updated based on the direction discussed.. I'm kind of on the
>> fence about whether its better. Its nice there is no h1 in there.
>>
>> ---------- Forwarded message ----------
>> From: <internet-drafts@ietf.org>;
>> Date: Thu, Oct 26, 2017 at 1:30 PM
>> Subject: New Version Notification for draft-mcmanus-httpbis-h2-
>> websockets-01.txt
>> To: Patrick McManus <mcmanus@ducksong.com>;
>>
>>
>>
>> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-01.txt
>> has been successfully submitted by Patrick McManus and posted to the
>> IETF repository.
>>
>> Name:           draft-mcmanus-httpbis-h2-websockets
>> Revision:       01
>> Title:          Bootstrapping WebSockets with HTTP/2
>> Document date:  2017-10-26
>> Group:          Individual Submission
>> Pages:          9
>> URL:            https://www.ietf.org/internet-
>> drafts/draft-mcmanus-httpbis-h2-websockets-01.txt
>> Status:         https://datatracker.ietf.org/
>> doc/draft-mcmanus-httpbis-h2-websockets/
>> Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-
>> websockets-01
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-
>> httpbis-h2-websockets-01
>> Diff:           https://www.ietf.org/rfcdiff?
>> url2=draft-mcmanus-httpbis-h2-websockets-01
>>
>> Abstract:
>>    This document defines a mechanism for running the WebSocket Protocol
>>    [RFC6455] over a single stream of an HTTP/2 connection.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
> --
> *John Fallows*
> CTO*  |  *📞+1.415.215.6597
> *----------------------------------------------------------------------*
> KAAZING >|<  when real-time matters™
> kaazing.com/kwic <http://www.kaazing.com/kwic>  |  Blog
> <http://blog.kaazing.com/>  |  Twitter <https://twitter.com/kaazing>
>