From nobody Sun Oct 15 08:43:12 2017 Return-Path: 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 2A0F0132031 for ; Sun, 15 Oct 2017 08:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.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 USwTOIesS5vj for ; Sun, 15 Oct 2017 08:43:08 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 B44E41323B4 for ; Sun, 15 Oct 2017 08:43:08 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i124so29085172wmf.3 for ; Sun, 15 Oct 2017 08:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sosseUSf1jcdxeBoov+R2W9mDUBRyglrddu33bYyISs=; b=R4I45gde+pAX7vBYXoDGkior4aA/2pcDIvf624U6uUECdQEhqYkNgFuJ24pz7JEa5D nWuV/0RQLBfuNGP35BxZA3gSew6o3cRdB+1vNryqTCmTZQ9PXeEmn1M8jtEddWLVpMVn 6zobn4cTVymH1vUOUctZlu5BgkF5OOMebCbbX8j4MLgjqv/5pZ81Bekngq+wZSfX/MZU DvDyk3Qt+wptXyNSmd33EKaihG6LUXlykWh9lSEtWnkxt3Dqv8Eqs36P8PiSlP4y7pdR WIjTxu4Wj/qefXaGTqflX7i7009BJHmbCw66bMJN96XS7GHFbAvvhv+S2ddbD8POeDbK b7uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sosseUSf1jcdxeBoov+R2W9mDUBRyglrddu33bYyISs=; b=e6DVzBlSE9QP8UXrCEbqZIm6GnhoxnrAnv9RSvRSO7BabhEUgy+/4yfa85xvfNYRAT 8y4YHRVbkd74gxC0xsVvGvuwYS2ON7bZMgo7hsta5jIxlM1mEt66FzoenpUUnPjd3n7S 6Dy81eEJMtdyuFD9W66OTy8lxL3PVaF9qHX6ZkXnOI3+rXPemBhs2B2UE/m+hPPw1c5G qjJserrYLZSSM60PBu7gKj5J67MpstaaAjrffjoqqG3wM/FQO2SbaprqY+DT0dBS9TsR gdnUdBLSO5HIkWjU/fqJIeQ4nmo+kstKm4rP313LtxlhXmhuIVKTxb30+CX/Q1qX5Ogr IrJw== X-Gm-Message-State: AMCzsaWh49rRV7HcXaE4xZEfnlGmmVlcxLkibzFJL+vzeGEWfaVbC/TH iEAvLHC//7Xe03n5Fbz1JG5MORb2VH8= X-Google-Smtp-Source: ABhQp+Q6flxiegBNyKImrOLixsJPnFhmpiLSplHd+SkMv17Ov56+jbP1dClNxtKDa2ZXkIVkVFWG6w== X-Received: by 10.28.158.72 with SMTP id h69mr5119672wme.83.1508082186827; Sun, 15 Oct 2017 08:43:06 -0700 (PDT) Received: from [100.93.91.185] ([213.205.251.89]) by smtp.gmail.com with ESMTPSA id 64sm3190471wrk.46.2017.10.15.08.43.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Oct 2017 08:43:05 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3BF58F39-4BC3-4410-80D4-E857D2E031E2 Mime-Version: 1.0 (1.0) From: Cory Benfield X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Sun, 15 Oct 2017 08:43:02 -0700 Cc: HTTP Working Group , hybi Content-Transfer-Encoding: 7bit Message-Id: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> To: Patrick McManus Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 15:43:11 -0000 --Apple-Mail-3BF58F39-4BC3-4410-80D4-E857D2E031E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Doesn=E2=80=99t the introduction of a new pseudo-header field violate RFC 75= 40 Section 8.1.2.1, which says endpoints MUST NOT generate new pseudo-header= fields? Or is the position that that MUST NOT implicitly applies only if there are n= o negotiated extensions in use? Cory > On 15 Oct 2017, at 07:12, Patrick McManus wrote: >=20 > FYI - also see https://github.com/mcmanus/draft-h2ws/blob/master/README.md= >=20 > Comments, expressions of interest, etc are very welcome. >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Sun, Oct 15, 2017 at 10:08 AM > Subject: New Version Notification for draft-mcmanus-httpbis-h2-websockets-= 00.txt > To: Patrick McManus >=20 >=20 >=20 > A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt > has been successfully submitted by Patrick McManus and posted to the > IETF repository. >=20 > Name: draft-mcmanus-httpbis-h2-websockets > Revision: 00 > Title: Bootstrapping WebSockets with HTTP/2 > Document date: 2017-10-15 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis= -h2-websockets-00.txt > Status: https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-= websockets/ > Htmlized: https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-webso= ckets-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbi= s-h2-websockets-00 >=20 >=20 > Abstract: > This document defines a mechanism for running the WebSocket Protocol > [RFC6455] over a single stream of an HTTP/2 connection. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail-3BF58F39-4BC3-4410-80D4-E857D2E031E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Doesn=E2=80=99t the introdu= ction of a new pseudo-header field violate RFC 7540 Section 8.1.2.1, which s= ays endpoints MUST NOT generate new pseudo-header fields?

Or is the position that that MUST NOT implicitly applies only if ther= e are no negotiated extensions in use?

Cory

On 15 Oct 2017, at 07:12, Patrick McManus <mcmanus@ducksong.com> wrote:


Comments,= expressions of interest, etc are very welcome.


---------- Forwarded message ---------= -
From: <internet-drafts@ietf.org>Date: Sun, Oct 15, 2017 at 10:08 AM
Subject: New Version Notification fo= r draft-mcmanus-httpbis-h2-websockets-00.txt
To: Patrick McManus <mcmanus@ducksong.com>


=
A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt
has been successfully submitted by Patrick McManus and posted to the
IETF repository.

Name:           draft-mcmanus-httpbis-h2-= websockets
Revision:       00
Title:          Bootstrapping WebSockets with HTTP/= 2
Document date:  2017-10-15
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-mcman= us-httpbis-h2-websockets-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-= websockets/
Htmlized:       = https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-httpb= is-h2-websockets-00


Abstract:
   This document defines a mechanism for running the WebSocket Pro= tocol
   [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


= --Apple-Mail-3BF58F39-4BC3-4410-80D4-E857D2E031E2-- From nobody Sun Oct 15 12:25:12 2017 Return-Path: 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 9AE2B133078 for ; Sun, 15 Oct 2017 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kSt7RFFp0_4J for ; Sun, 15 Oct 2017 12:25:07 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30310124B18 for ; Sun, 15 Oct 2017 12:25:06 -0700 (PDT) Date: Mon, 16 Oct 2017 03:24:28 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: hybi@ietf.org, Cory Benfield , Patrick McManus CC: hybi ,HTTP Working Group From: Andy Green Message-ID: <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 19:25:10 -0000 On October 15, 2017 11:43:02 PM GMT+08:00, Cory Benfield wrote: Cory, thanks for cc-ing hybi=2E I reply with comments about the draft fir= st=2E 1) it's great that after a few years someone with influence woke up to the= fact ws was frozen out of h2 and that, as was publicly foreseen by several= people, it would be a PITA to leave it at "let them eat h1"=2E 2) 'From the draft: 'A server offering both HTTP/1=2E1 and WebSocket servi= ces can do so from the same instance and same port although they require se= parate TCP connections=2E Moving a server to HTTP/2 and WebSocket services = requires a separate port and protocol stack for the sole purpose of bootstr= apping WebSockets=2E This is a significant administrative burden and may no= t even be possible in the case of large amounts of deployed markup pointing= at the old single name and port=2E '' This simply isn't true, for example libwebsockets supports h1, h2 and wss = all on :443 simultaneously; https://libwebsockets=2Eorg itself runs on that= today=2E Nothing stops it except decisions made by the server authors=2E = "Some popular implementations are not architechted in a way the same liste= n port can accept sockets destined for h1, h2, and ws" or similar would be = more correct=2E 3) The general approach in the draft is okay=2E It just adds ws to h2 whi= ch is what was always needed=2E The general occurance of DATA in each direc= tion differs from that implied by http h2 usage, it's not a problem but may= be should be noted=2E 4) The draft should spell out it carries ws payload unchanged in h2 frames= =2E In particular ws has this xor "masking" stuff that is just not needed = for end-end h2 ws connections=2E It's a shame this scheme leaves eliminati= ng the bloat on the table but better (bloatwise) plans have gone around in = circles for years, this draft marks a browser implementor actually wanting = to implement something related to h2 ws for the first time I heard of=2E=2E= =2E 5) Hybi originally did the ws handshake key dance with hashes to ensure th= ere were no inadvertant ws handshakes where one side did not really speak i= t=2E It is not required on h2, since if it has the SETTINGS enabled, it as= serts it speaks it, although I get it a client for a stream may not know it= went over h2, only know h1 and require the dance=2E So the old dance shou= ld be optional I think=2E 6) If you make the ws key dance roundtrip optional, something to keep h1 c= lients happy who don't know they're on h2, then you can PUSH_PROMISE a ws u= pgrade on a specific subprotocol unilaterally, eliminating roundtrips=2E I= f you are serving html with a script that wants to make the ws connection b= ack, it's a very good bet the client would take up the PUSH_PROMISE with ve= ry nice latency improvement=2E >Doesn=E2=80=99t the introduction of a new pseudo-header field violate RFC= 7540 >Section 8=2E1=2E2=2E1, which says endpoints MUST NOT generate new >pseudo-header fields? > >Or is the position that that MUST NOT implicitly applies only if there >are no negotiated extensions in use? That is a good point=2E=2E=2E won't a new Sec-whatever do? Being able to = use whatever it is in PUSH_PROMISE to unilaterally offer an unambiguous pre= -upgraded ws stream would be very nice=2E -Andy >Cory > >> On 15 Oct 2017, at 07:12, Patrick McManus >wrote: >>=20 >> FYI - also see >https://github=2Ecom/mcmanus/draft-h2ws/blob/master/README=2Emd >>=20 >> Comments, expressions of interest, etc are very welcome=2E >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Oct 15, 2017 at 10:08 AM >> Subject: New Version Notification for >draft-mcmanus-httpbis-h2-websockets-00=2Etxt >> To: Patrick McManus >>=20 >>=20 >>=20 >> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00=2Etxt >> has been successfully submitted by Patrick McManus and posted to the >> IETF repository=2E >>=20 >> Name: draft-mcmanus-httpbis-h2-websockets >> Revision: 00 >> Title: Bootstrapping WebSockets with HTTP/2 >> Document date: 2017-10-15 >> Group: Individual Submission >> Pages: 7 >> URL: =20 >https://www=2Eietf=2Eorg/internet-drafts/draft-mcmanus-httpbis-h2-websock= ets-00=2Etxt >> Status: =20 >https://datatracker=2Eietf=2Eorg/doc/draft-mcmanus-httpbis-h2-websockets/ >> Htmlized: =20 >https://tools=2Eietf=2Eorg/html/draft-mcmanus-httpbis-h2-websockets-00 >> Htmlized: =20 >https://datatracker=2Eietf=2Eorg/doc/html/draft-mcmanus-httpbis-h2-websoc= kets-00 >>=20 >>=20 >> Abstract: >> This document defines a mechanism for running the WebSocket >Protocol >> [RFC6455] over a single stream of an HTTP/2 connection=2E >>=20 >>=20 >>=20 >>=20 >> 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=2Eietf=2Eorg= =2E >>=20 >> The IETF Secretariat >>=20 >>=20 From nobody Sun Oct 15 13:39:06 2017 Return-Path: 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 D6C9B1331DC for ; Sun, 15 Oct 2017 13:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 pl_HP6WkJQP7 for ; Sun, 15 Oct 2017 13:39:03 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 53820132F3E for ; Sun, 15 Oct 2017 13:39:03 -0700 (PDT) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id B864D3A021 for ; Sun, 15 Oct 2017 16:39:01 -0400 (EDT) Received: by mail-lf0-f49.google.com with SMTP id k40so14795547lfi.4 for ; Sun, 15 Oct 2017 13:39:01 -0700 (PDT) X-Gm-Message-State: AMCzsaXx+zXWdtiSMlfTd0W1WRJUyv15RTZxI80UJWy4GaKhoxFLK1dh bA0QN0F/Ca085+cyvzFXXi5UBAuwVpPVdJdKBXg= X-Google-Smtp-Source: ABhQp+TiDh5i55PxgfSS4VwzO6gWfYnLeyTBxKuRTuHXqnbCcubHzlPmEkQLgt5jHGZK+lWu+F31bHZAqbn6jYaY1IQ= X-Received: by 10.46.32.81 with SMTP id g78mr3142658ljg.49.1508099940335; Sun, 15 Oct 2017 13:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Sun, 15 Oct 2017 13:38:59 -0700 (PDT) In-Reply-To: <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> From: Patrick McManus Date: Sun, 15 Oct 2017 16:38:59 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andy Green Cc: hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: multipart/alternative; boundary="001a1142bd383ac647055b9be101" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 20:39:06 -0000 --001a1142bd383ac647055b9be101 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Andy - it sounds like my 2 mails on this thread mght not have been posted to hybi? I'll try here with @mozilla.com addr. Thanks for the note. On Sun, Oct 15, 2017 at 3:24 PM, Andy Green wrote: > > 2) > This simply isn't true, thanks. I'll rephrase > 4) The draft should spell out it carries ws payload unchanged in h2 > frames. Streams that have been successfully established as protocol tunnels proceed to establish and utilize the WebSocket Protocol using the procedure defined by [RFC6455 ] treating the stream as if were the connection in that specification. Obviously there are approaches that could do far more significant things to the protocol. This is a shim for bootstrapping 6455, otherwise 6455 remains in tact. 5) Hybi originally did the ws handshake key dance with hashes to ensure > there were no inadvertant ws handshakes see 4. > 6) If you make the ws key dance roundtrip optional, something to keep h1 > clients happy who don't know they're on h2, then you can PUSH_PROMISE a w= s > upgrade on a specific subprotocol unilaterally, eliminating roundtrips. = If > you are serving html with a you can only push safe methods. connect is not safe. Again, I agree you could remove an rtt (or probably 2) with a different approach at a cost of higher complexity and changes. That's not the target here. \ > >Doesn=E2=80=99t the introduction of a new pseudo-header field violate RF= C 7540 > >Section 8.1.2.1, which says endpoints MUST NOT generate new > >pseudo-header fields? > > > >Or is the position that that MUST NOT implicitly applies only if there > >are no negotiated extensions in use? > > That is a good point... won't a new Sec-whatever do? Being able to use > whatever it is in PUSH_PROMISE to unilaterally offer an unambiguous > pre-upgraded ws stream would be very nice. > I answered this is a message that probably wasn't posted to hybi https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0034.html.. tl;dr; an opt-in extension lets you amend 7540 in ways that would be protocol violations without the opt-in. pseudo-headers are meant to control protocol level features and are unique to that version of the protocol - so this helps ensure that the Sec- header wasn't introduced by some other non h2 application . -Patrick > -Andy > > >Cory > > > >> On 15 Oct 2017, at 07:12, Patrick McManus > >wrote: > >> > >> FYI - also see > >https://github.com/mcmanus/draft-h2ws/blob/master/README.md > >> > >> Comments, expressions of interest, etc are very welcome. > >> > >> > >> ---------- Forwarded message ---------- > >> From: > >> Date: Sun, Oct 15, 2017 at 10:08 AM > >> Subject: New Version Notification for > >draft-mcmanus-httpbis-h2-websockets-00.txt > >> To: Patrick McManus > >> > >> > >> > >> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt > >> has been successfully submitted by Patrick McManus and posted to the > >> IETF repository. > >> > >> Name: draft-mcmanus-httpbis-h2-websockets > >> Revision: 00 > >> Title: Bootstrapping WebSockets with HTTP/2 > >> Document date: 2017-10-15 > >> Group: Individual Submission > >> Pages: 7 > >> URL: > >https://www.ietf.org/internet-drafts/draft-mcmanus- > httpbis-h2-websockets-00.txt > >> Status: > >https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ > >> Htmlized: > >https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00 > >> Htmlized: > >https://datatracker.ietf.org/doc/html/draft-mcmanus- > httpbis-h2-websockets-00 > >> > >> > >> 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 > >> > >> > > --001a1142bd383ac647055b9be101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Andy - it sounds like my 2 mails on this thread m= ght not have been posted to hybi? I'll try here with @mozilla.com addr. Thanks for the note.

=


On Sun, Oct 15, 2017 at 3:24 PM, Andy Green <andy@warmcat.com> wrote:

2)
This simply isn't true,

thanks. I'l= l rephrase
=C2=A0
4) The draft should spell out it carries ws payload unchanged in h2 frames.= =C2=A0 

   Str=
eams that have been successfully established as protocol tunnels
   proceed to establish and utilize the WebSocket Protocol using the
   procedure defined by [RFC6455] treating the stream=
 as if were the
   connection in that specification.
=C2=A0
Obvio= usly there are approaches that could do far more significant things to the = protocol. This is a shim for bootstrapping 6455, otherwise 6455 remains in = tact.

5) Hybi originally did the ws handshake key dance with hashes to ensure the= re were no inadvertant ws handshakes

see 4.=


6) If you make the ws key dance roundtrip optional, something to keep h1 cl= ients happy who don't know they're on h2, then you can PUSH_PROMISE= a ws upgrade on a specific subprotocol unilaterally, eliminating roundtrip= s.=C2=A0 If you are serving html with a

yo= u can only push safe methods. connect is not safe. Again, I agree you could= remove an rtt (or probably 2) with a different approach at a cost of highe= r complexity and changes. That's not the target here.
\
<= span class=3D"gmail-"> >Doesn=E2=80=99t the introduction of a new pseudo-header field violate R= FC 7540
>Section 8.1.2.1, which says endpoints MUST NOT generate new
>pseudo-header fields?
>
>Or is the position that that MUST NOT implicitly applies only if there<= br> >are no negotiated extensions in use?

That is a good point... won't a new Sec-whatever do?=C2=A0 Being= able to use whatever it is in PUSH_PROMISE to unilaterally offer an unambi= guous pre-upgraded ws stream would be very nice.

<= /div>
I answered this is a message that probably wasn't posted to h= ybi https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/00= 34.html.. tl;dr; an opt-in extension lets you amend 7540 in ways that w= ould be protocol violations without the opt-in.

pseudo-headers are meant to control protocol level features and are uniq= ue to that version of the protocol - so this helps ensure that the Sec- hea= der wasn't introduced by some other non h2 application .

=
-Patrick


-Andy

>Cory
>
>> On 15 Oct 2017, at 07:12, Patrick McManus <mcmanus@ducksong.com>
>wrote:
>>
>> FYI - also see
>https://github.com/mcmanus/draft= -h2ws/blob/master/README.md
>>
>> Comments, expressions of interest, etc are very welcome.
>>
>>
>> ---------- Forwarded message ----------
>> From: <internet-dra= fts@ietf.org>
>> Date: Sun, Oct 15, 2017 at 10:08 AM
>> Subject: New Version Notification for
>draft-mcmanus-httpbis-h2-websockets-00.txt
>> To: Patrick McManus <mc= manus@ducksong.com>
>>
>>
>>
>> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.= txt
>> has been successfully submitted by Patrick McManus and posted to t= he
>> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mcmanus-httpbi= s-h2-websockets
>> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bootstrapping WebSockets = with HTTP/2
>> Document date:=C2=A0 2017-10-15
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
>> URL:
>https://www.ietf.= org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt
>> Status:
>https://datatracker.ietf.or= g/doc/draft-mcmanus-httpbis-h2-websockets/
>> Htmlized:
>https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
>> Htmlized:
>https://datatracker.= ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00
>>
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document defines a mechanism for running the Web= Socket
>Protocol
>>=C2=A0 =C2=A0 [RFC6455] over a single stream of an HTTP/2 connectio= n.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>


--001a1142bd383ac647055b9be101-- From nobody Sun Oct 15 19:39:55 2017 Return-Path: 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 957FC132332 for ; Sun, 15 Oct 2017 19:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gFltXS5iNvU4 for ; Sun, 15 Oct 2017 19:39:47 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4B51320DC for ; Sun, 15 Oct 2017 19:39:47 -0700 (PDT) To: Patrick McManus Cc: hybi , Cory Benfield , Patrick McManus , HTTP Working Group References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> From: Andy Green Message-ID: Date: Mon, 16 Oct 2017 10:38:56 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 02:39:53 -0000 On 10/16/2017 04:38 AM, Patrick McManus wrote: > Hey Andy - it sounds like my 2 mails on this thread mght not have been > posted to hybi? I'll try here with @mozilla.com > addr. Thanks for the note. > thanks. I'll rephrase > > 4) The draft should spell out it carries ws payload unchanged in h2 > frames. > > > Streams that have been successfully established as protocol tunnels > proceed to establish and utilize the WebSocket Protocol using the > procedure defined by [RFC6455 ] treating the stream as if were the > connection in that specification. > > Obviously there are approaches that could do far more significant things > to the protocol. This is a shim for bootstrapping 6455, otherwise 6455 > remains in tact. Yes... it should probably spell that out for DATA though, something like: "Once upgraded, the h2 stream is used to transport the ws frames by enclosing them in h2 DATA frames. There is no specific relationship between h2 DATA fragment sizes carrying the ws frames and the ws frame sizes; the h2 frames may refragment the original ws frames arbitrarily, eg to meet mux latency goals across multiple streams. Although the DATA frames used for encapsulation are not distinguishable from DATA frames used for h2 http transport, note unlike DATA frames used for http they are not restricted in either direction by content-length and they may appear in either direction continuously, until END_STREAM appears.". > 5) Hybi originally did the ws handshake key dance with hashes to > ensure there were no inadvertant ws handshakes > > > see 4. Not suggesting to change that... > 6) If you make the ws key dance roundtrip optional, something to > keep h1 clients happy who don't know they're on h2, then you can > PUSH_PROMISE a ws upgrade on a specific subprotocol unilaterally, > eliminating roundtrips.  If you are serving html with a > > you can only push safe methods. connect is not safe. Again, I agree you > could remove an rtt (or probably 2) with a different approach at a cost > of higher complexity and changes. That's not the target here. Well, it looks like you don't want to do it. This thing would be an optional optimization it doesn't affect what you have at the moment. PUSH_PROMISE has some restrictions as defined in RFC7450 8.2, like "Promised requests MUST be cacheable" which would need working around. It's also slightly different in that ws is bidirectional, normal PUSH_PROMISE the server manages delivering the promise or not, and the client can accept stuff to cache at any time or RST him. But with ws PUSH_PROMISE content, there'd be a race between the script trying to instantiate the ws connection after the HTML was received so it has a context to use the ws link, and the server deciding to try send something. It can be handled by defining the initial tx window to be 0 for ws PUSH_PROMISE streams and the client must explicitly allow it to send. Here's what I think it means for RTT... first the default as it is Client Server - SETTINGS - SETTINGS - GET /index.html - 200 HEADERS + DATA - :method CONNECT - 200 HEADERS - DATA ws handshake - DATA ws handshake final - DATA ... - DATA... So after the h2 link is up, he needs 3 x roundtrips to send some ws data. With an optional PUSH_PROMISE that the client feels he can use... - SETTINGS - SETTINGS - GET /index.html - 200 HEADERS + DATA - PUSH_PROMISE ws contains ws handshake final - WINDOW_UPDATE (see below) - DATA ... - DATA... It's just one (client -> server) or 1.5 (server -> client) roundtrips instead of 3. Anyway if nobody else wants it, no point worrying about it. -Andy > \ > > >Doesn’t the introduction of a new pseudo-header field violate RFC 7540 > >Section 8.1.2.1, which says endpoints MUST NOT generate new > >pseudo-header fields? > > > >Or is the position that that MUST NOT implicitly applies only if there > >are no negotiated extensions in use? > > That is a good point... won't a new Sec-whatever do?  Being able to > use whatever it is in PUSH_PROMISE to unilaterally offer an > unambiguous pre-upgraded ws stream would be very nice. > > > I answered this is a message that probably wasn't posted to hybi > https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0034.html.. > tl;dr; an opt-in extension lets you amend 7540 in ways that would be > protocol violations without the opt-in. > > pseudo-headers are meant to control protocol level features and are > unique to that version of the protocol - so this helps ensure that the > Sec- header wasn't introduced by some other non h2 application . > > -Patrick > > > -Andy > > >Cory > > > >> On 15 Oct 2017, at 07:12, Patrick McManus > > >wrote: > >> > >> FYI - also see > >https://github.com/mcmanus/draft-h2ws/blob/master/README.md > > >> > >> Comments, expressions of interest, etc are very welcome. > >> > >> > >> ---------- Forwarded message ---------- > >> From: > > >> Date: Sun, Oct 15, 2017 at 10:08 AM > >> Subject: New Version Notification for > >draft-mcmanus-httpbis-h2-websockets-00.txt > >> To: Patrick McManus > > >> > >> > >> > >> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt > >> has been successfully submitted by Patrick McManus and posted to the > >> IETF repository. > >> > >> Name:           draft-mcmanus-httpbis-h2-websockets > >> Revision:       00 > >> Title:          Bootstrapping WebSockets with HTTP/2 > >> Document date:  2017-10-15 > >> Group:          Individual Submission > >> Pages:          7 > >> URL: > >https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt > >> Status: > >https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ > >> Htmlized: > >https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00 > > >> Htmlized: > >https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00 > >> > >> > >> 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 > >> > >> > > From nobody Sun Oct 15 19:51:57 2017 Return-Path: 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 CCD5B13416B for ; Sun, 15 Oct 2017 19:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 7ArrJ92MB8mg for ; Sun, 15 Oct 2017 19:51:53 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 992E8126BF3 for ; Sun, 15 Oct 2017 19:51:53 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id h6so2770396oia.10 for ; Sun, 15 Oct 2017 19:51:53 -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=IW3p1ZaTs1T5ZspgWTRHVOenX2XnRF8dpmT8U9lQags=; b=J8fnwhwx8sFactrv5LzY7l0+8PgVf2yVe9+VUkFkYMC3mzKFGBryntEMN6JhKbPKBl LsJtC2X9SUdfHbuufxHnE1qW9DusS5/KNmbJ9VBrKMCQZnDMdteEHVkhvdxPD1ODLSIb R/WqRsomXUlNFt/DpYJnYUIU2zLYdTthAWzVNy1cGfD2DWKUydyWpTpFnPtKiNuG71+C auCVaksvFzaueZsGCDVI32CoifALfzcsnaqXJnifNre1I+CGknxBO7tBxb/HECdF1ae6 9GCdJ+WvSiKmp0q9O2+ayhp6S5ac+IGInrscjtcWDA1qd1PFowjzC95TSMI30/J+ZcuZ dtWQ== 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=IW3p1ZaTs1T5ZspgWTRHVOenX2XnRF8dpmT8U9lQags=; b=YUlkM1A/GYPBy3CkdYyTmiu6IYT18db4AUYR5MCNvq5sSK5VzW5y+mi4Zhz/THtHuf aiSa3GffXeKeOK90qoVInqTntLXLTb2YShdFuPlnO2wsy8C3cQgOro+ZoDEChHJmf4nd g+BxX/x3VEkyhahMt8fzbhyaSUDHzrM2JfuHj0B7QJGljUrYs5venwafbbK7pGDWPAA5 fqntLdZ+/iZEq3NZZ0naQgTNbvGcLhX4EhgHnXQt7y0odZv5lPz9LELWdn23FBRDZAMk kdEGWueiWvUD0NnjFatkdlkkX2p3cowbtBmv+UCsnHZye6Zzw4n74DaplvOyjr0CJffg gNFw== X-Gm-Message-State: AMCzsaWZrUBgPcpWKq+Okoz5bplnT2XQm2+fZ/QWirexADlvd1bbHqOh 6MPpxbDpDZxI2ruJF48wvluS1tAD7P0u08klNjE= X-Google-Smtp-Source: ABhQp+T/RdUhDLGUmxKPKsDIL8pix0tQxAIWzPSb6KsmIAmafQBhc3XQ8Aho3rm6ibc/yCHIS6uffjKLsHdpE37xs6g= X-Received: by 10.202.166.141 with SMTP id t13mr4752096oij.392.1508122312861; Sun, 15 Oct 2017 19:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 19:51:52 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> From: Martin Thomson Date: Mon, 16 Oct 2017 13:51:52 +1100 Message-ID: To: Andy Green Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 02:51:56 -0000 On Mon, Oct 16, 2017 at 1:38 PM, Andy Green wrote: > Here's what I think it means for RTT... first the default as it is > > Client Server > > - SETTINGS - SETTINGS > - GET /index.html > - 200 HEADERS + DATA > > - :method CONNECT > - 200 HEADERS > > - DATA ws handshake > - DATA ws handshake final > > - DATA ... - DATA... > > So after the h2 link is up, he needs 3 x roundtrips to send some ws data. I think that you are exaggerating the cost here. The ws handshake and CONNECT can be sent together. The only real burden that Patrick's design adds is the need to test that the server is willing to use this design. FWIW, if this were me, I would look at trimming the websocket handshake instead. Much of the overhead there is what will hurt the overall latency. If you took the setting as an indication that this was an acceptable protocol, you could remove all the Upgrade business and just start sending ws frames. But I think that Patrick is right to start with the minimal thing; I would recommend only doing that with a new protocol identifier. From nobody Sun Oct 15 19:58:45 2017 Return-Path: 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 8CF98133341 for ; Sun, 15 Oct 2017 19:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SphjNamWKDE5 for ; Sun, 15 Oct 2017 19:58:42 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E906B126BF3 for ; Sun, 15 Oct 2017 19:58:41 -0700 (PDT) To: Martin Thomson Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> From: Andy Green Message-ID: Date: Mon, 16 Oct 2017 10:57:53 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 02:58:43 -0000 On 10/16/2017 10:51 AM, Martin Thomson wrote: > On Mon, Oct 16, 2017 at 1:38 PM, Andy Green wrote: >> Here's what I think it means for RTT... first the default as it is >> >> Client Server >> >> - SETTINGS - SETTINGS >> - GET /index.html >> - 200 HEADERS + DATA >> >> - :method CONNECT >> - 200 HEADERS >> >> - DATA ws handshake >> - DATA ws handshake final >> >> - DATA ... - DATA... >> >> So after the h2 link is up, he needs 3 x roundtrips to send some ws data. > > I think that you are exaggerating the cost here. The ws handshake and Eh... why do you say that? It takes less than 3 RTs? > CONNECT can be sent together. The only real burden that Patrick's > design adds is the need to test that the server is willing to use this > design. Maybe it's not clear from the formatting, but I based this from p4 of Patrick's draft, here is the original [[ From Client ]] [[ From Server ]] SETTINGS ENABLE_CONNECT_PROTOCOL = 1 HEADERS + END_HEADERS :method = CONNECT :protocol = websocket :scheme = wss :path = /chat :authority = server.example.com:443 HEADERS + END_HEADERS :status = 200 DATA GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 DATA HTTP/1.1 101 Plead The Fifth Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat DATA WebSocket Data DATA + END_STREAM WebSocket Data DATA + END_STREAM WebSocket Data That is 3 RTT, right? > FWIW, if this were me, I would look at trimming the websocket > handshake instead. Much of the overhead there is what will hurt the He needs to support dumb http/1 ws clients that find themselves hitching a ride on a h2 bundle. So they need all the headers they expect. That's why I don't suggest any changes there, but as an optimization for h2-aware ws client skip all that legacy junk and just provide the end result in the PUSH_PROMISE. > overall latency. If you took the setting as an indication that this > was an acceptable protocol, you could remove all the Upgrade business > and just start sending ws frames. But I think that Patrick is right > to start with the minimal thing; I would recommend only doing that > with a new protocol identifier. That is what I suggested on both counts :-) -Andy From nobody Sun Oct 15 20:01:51 2017 Return-Path: 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 95402133344 for ; Sun, 15 Oct 2017 20:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 mfGpaV4dzkGL for ; Sun, 15 Oct 2017 20:01:47 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 685D2126BF3 for ; Sun, 15 Oct 2017 20:01:47 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id n82so23140400oig.3 for ; Sun, 15 Oct 2017 20:01:47 -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=zHjphNrKpPpTCrMXPaYm9g7FdhHme4QjKUeL32UxWHU=; b=ijA7+RkT8Q1qOVOVqCnUE7tKOAdX5puazqEGUbW69TOvmSOukp4HcjPqGkRcFC1RMq 0Wn4YWtuX/B8kzx9NCqgskvd++GS2IDZRuGe7B5YhUgoFUqAJ3WJlBwkQsitjFbUe7Xj 0OKhf/fhMw6cWUCI66dzx9zA216van3rwIIRpE4MU7IX/SKOLeCe5dlKJ5yQvTpFmUG7 gTyzgF3ea32BVlmXM8EEYZtai6E2MQsEa6RYY75VZ33MDGJQfo0QJ7WPTMD14USK9z+I GAtdGou3CX/BNTmKRESnKx5Ev0Trwe/L4vNbWYxUtdOGjNQcBgJq1VqiFD8wAuiaqzNm +lPA== 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=zHjphNrKpPpTCrMXPaYm9g7FdhHme4QjKUeL32UxWHU=; b=I00pxBITkrGpnkLbvWbc53RiP5IWyCvo/c1fBPdw/ZACKCX3TiTGcNbFP4+Qml+cA7 4/8VETuCwatTj7aGpGyeKw+7vXruCs8tLKyfYhkq+VKJoO94KIZ1HMui4e1pMi0gfuT1 YGoN4Rp74j6HDT4i5qORNkftwswOD2ugK4Mj7cTXE2xxs76NSWt24uwmA5URO5Eh+EOv 6vTcmC4b0c9//qcgEkDuMZeln45qNlMSzoNQxr/FISwafIKDbIDw81c9l5LFRhbRTyKs THIGaUbLTsMvYRNKe2fZECD8TLtEyBtoqKcjT90AjIGaSG/ztM63ztlZH5DCnjHEKAjW WiAA== X-Gm-Message-State: AMCzsaWOtHaj7Inco4HRcfLaciG7F+60V3FsnSZH25QLVxh+AQ6eRfgA VZrccEwW8foarRo3PuDcgANXw62yzahxI5Nj18o= X-Google-Smtp-Source: ABhQp+Q+1BKc/Invub68dwzXnU6Z7Hri+R7ImLj+IxN+yTHhFNZpRiZ6ig4oJdA/D7C2RnsnYHscagkr/pZ5mOh89QA= X-Received: by 10.202.108.2 with SMTP id h2mr4098675oic.177.1508122906773; Sun, 15 Oct 2017 20:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 20:01:46 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> From: Martin Thomson Date: Mon, 16 Oct 2017 14:01:46 +1100 Message-ID: To: Andy Green Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 03:01:48 -0000 On Mon, Oct 16, 2017 at 1:57 PM, Andy Green wrote: > That is 3 RTT, right? I'm basing this off how I understand h2 to work, and the example in the draft shows an unnecessary extra RTT; that's all. From nobody Sun Oct 15 20:09:07 2017 Return-Path: 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 29D2213337F for ; Sun, 15 Oct 2017 20:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JIErle_3FKCj for ; Sun, 15 Oct 2017 20:09:05 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434711320DC for ; Sun, 15 Oct 2017 20:09:05 -0700 (PDT) To: Martin Thomson Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> From: Andy Green Message-ID: <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> Date: Mon, 16 Oct 2017 11:08:29 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 03:09:06 -0000 On 10/16/2017 11:01 AM, Martin Thomson wrote: > On Mon, Oct 16, 2017 at 1:57 PM, Andy Green wrote: >>> I think that you are exaggerating the cost here. The ws handshake and >>Eh... why do you say that? It takes less than 3 RTs? >> That is 3 RTT, right? > > I'm basing this off how I understand h2 to work, and the example in > the draft shows an unnecessary extra RTT; that's all. > Patrick himself says "...Again, I agree you could remove an rtt (or probably 2)..." I think you misunderstood something... as it is he has to wait for the SETTINGs to tell him it's possible, wait for the CONNECT and response and wait for the ws handshake to go through before he can send something. It's 3 x RTT AFAICS and nothing is "exaggerat[ed]". That's alright if it's the default situation for HTTP/1 ws guys... but there should be a way like PUSH_PROMISE to dispense will all that junk for what will be increasingly common native-h2 ws client. -Andy From nobody Sun Oct 15 20:57:30 2017 Return-Path: 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 646D01320CF for ; Sun, 15 Oct 2017 20:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 hnD9KZO1SpPy for ; Sun, 15 Oct 2017 20:57:27 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 67C3C1270AE for ; Sun, 15 Oct 2017 20:57:27 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w197so23237394oif.6 for ; Sun, 15 Oct 2017 20:57:27 -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=3iIXGZEG6a0lZLDsfNqTeqUTI9EeXm3fWtAwr5fXYG4=; b=DiWQWPHh+soTlAPDgcspDlfhCiOc9BE75zcXAuCVi2cJeZL19IkS8TfkoEZbLhzXX5 RDqwbgTs+jJVYWYqqwZKK1YAiELIG2iWWmpSpTYuIpFdFL0nvY+sQiuH4tth8fWpVufG /dEn6RexlTcanOEMIrw5mo+jS+3f3fusijELalCXbatq2woYwEghreTOeW24jovr1T9q zNNcYi5AzIqnO8+zJULzBsJE2fUiWEBxADfSIzSFergaOQ0O5SWmyTfkLY/F2ANJQSHd GjcpWdvw0NvTidMAzmU8AKAgJnJD8WnOHYWGSf/eTBfFqbP1LFlHho5yCj3JUjTt/7YF EuSA== 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=3iIXGZEG6a0lZLDsfNqTeqUTI9EeXm3fWtAwr5fXYG4=; b=i0JfpVXVrcJT6Nmuc16VoCxd6jU/KGAW5aLUdjPtZ69xhHar/4ujBpDdacxRhKSVBu wN4PIjrtptRpF7WC990QoRvE2Kvjdc501oG1JrUZazF63vksygSKGpoTsN7Yapx321SO OYy1MjKSj7rkauXvnJPSjVxWcTjzQpzJG6IE4G+Ewb3TVb3JeZfDFPXdYPwGM57yGNjR soS+NVd//oD0UTvPc1wzhQBJcZZIk4fYaFFLZkhbJRQNflrWO8CSe8Hq3MyZbZjOZjZJ YzwjNVCYfIn1vyT89OLSNDo/JpVoOlS88mtlwdl8eiAFohfTcxcN3aQ98M5FjGU1MMgr 3USA== X-Gm-Message-State: AMCzsaXMpUkBnhPJbMK3XqJmPsTL0JGEjyFPcrmwXccqT2nttrZa4e9o Y49CzbcRIVkU1YVbbj0X8KvjmppJ0hdDNOBuQ/g= X-Google-Smtp-Source: ABhQp+RLmedog/QDBgprkvEFzIM+2mdVTXhtKLfmodU3IwU/geGce7LazKdZq+V0z/GzjlL0CzJvcdoqPd2ADWa661o= X-Received: by 10.202.75.216 with SMTP id y207mr4865444oia.282.1508126246705; Sun, 15 Oct 2017 20:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 20:57:26 -0700 (PDT) In-Reply-To: <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Martin Thomson Date: Mon, 16 Oct 2017 14:57:26 +1100 Message-ID: To: Andy Green Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 03:57:28 -0000 On Mon, Oct 16, 2017 at 2:08 PM, Andy Green wrote: > I think you misunderstood something... as it is he has to wait for the > SETTINGs to tell him it's possible, wait for the CONNECT and response and > wait for the ws handshake to go through before he can send something. No, I'm just saying that if you proceed like the CONNECT will work, then you can save an RTT over that. Given that you have a clear indication that the server accepts WS, then you don't need to worry about this. Keep in mind that you don't have to wait a round trip for the server SETTINGS frame in TLS 1.3. That means that you aren't saving much with any of these extra steps. From nobody Sun Oct 15 21:07:24 2017 Return-Path: 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 CC5CB1320CF for ; Sun, 15 Oct 2017 21:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sJOpZYSv4qby for ; Sun, 15 Oct 2017 21:07:21 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B76126E64 for ; Sun, 15 Oct 2017 21:07:20 -0700 (PDT) To: Martin Thomson Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Andy Green Message-ID: Date: Mon, 16 Oct 2017 12:06:09 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 04:07:22 -0000 On 10/16/2017 11:57 AM, Martin Thomson wrote: > On Mon, Oct 16, 2017 at 2:08 PM, Andy Green wrote: >> I think you misunderstood something... as it is he has to wait for the >> SETTINGs to tell him it's possible, wait for the CONNECT and response and >> wait for the ws handshake to go through before he can send something. > > No, I'm just saying that if you proceed like the CONNECT will work, > then you can save an RTT over that. Given that you have a clear > indication that the server accepts WS, then you don't need to worry > about this. > > Keep in mind that you don't have to wait a round trip for the server > SETTINGS frame in TLS 1.3. That means that you aren't saving much > with any of these extra steps. > The sequence I gave for counting the RTT includes fetching the html with the script that wants to make the connection; until the client gets that he cannot start with the ws connection. This is the typical situation for ws connections and in the case the same h2 connection is providing everything, it will be the normal case there too. Client Server - SETTINGS - SETTINGS - GET /index.html - 200 HEADERS + DATA - :method CONNECT - 200 HEADERS - DATA ws handshake - DATA ws handshake final - DATA ... - DATA... So after the h2 link is up, he needs 3 x roundtrips to send some ws data. With an optional PUSH_PROMISE that the client feels he can use... - SETTINGS - SETTINGS - GET /index.html - 200 HEADERS + DATA - PUSH_PROMISE ws contains ws handshake final - WINDOW_UPDATE (see below) - DATA ... - DATA... What you are saying will save time I already assume is "for free" since it happens during the time the HTML is fetched. If I am missing the point, could you edit the above copied unchanged from my earlier mail to show me the point I am missing? -Andy From nobody Sun Oct 15 21:15:36 2017 Return-Path: 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 60CFE133528 for ; Sun, 15 Oct 2017 21:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 chfraP3U_gH4 for ; Sun, 15 Oct 2017 21:15:32 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 BEB671320CF for ; Sun, 15 Oct 2017 21:15:32 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id h6so2940433oia.10 for ; Sun, 15 Oct 2017 21:15:32 -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=nYMiaHAsohed1fFQG6W1caH5GIa3Wgv6EuFlzjosgro=; b=CfJCCP2RZP9RmAT8Bhb5+oxk0KMdkNL5GbP9++KmySVLEHsepKjSJu5zGhgDVhz4dl JTDFFwEMxft6qD18rRuyfWUC0f3853maWAtWDPXKntw3VBIcHKMNwRD3tu8ikO3dw4W0 nkgEpO8ySavLcbO9KJrmi/8psNhTrehNCWZRWag0WDFKl3UIdDREZhBfUOhFH72iaUtV 3PjBgEdocI2Pj0TRSNdBL2Otu2jH42sQ6riikjGF/aeG8QCZdIsMZBNwO2HCFpSU/H7Y jqIXVUSvynyEZeq6vxRl8qNwswq5ICU9HH9i7Mzu7JH5u+FgLd0xci6L/yz99ciS4S/b eC0w== 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=nYMiaHAsohed1fFQG6W1caH5GIa3Wgv6EuFlzjosgro=; b=aQbUruhcagfSbmUJ5KCfFS15ACLkMsAQUXbRubyt7HXzk2N9TX119r2+N1WnvRyyA5 ibgtiNUKzOJm9u5aZTLqa6Mqm9C0Y3/rdpJ6AdKq0ipzQdqhnLmvC6Tq8Dj0c9cbeFrs hgcnXjk/KdqzfajF6tSh/vTbFQ70OH/gFIwLFXRp3owTV/C37dZGLwF9D/bAZiRaNgln vs/kFuJyRwzvPFJ+R/LAO8Tce8g/HgRU2VPIWMgw3mMGoKmQ7HNo8E/6oeULyLhke70e vMVxXJitHLeYMdmdkGQJ7bHvLssSIy9N4jb2VSUzewJInm2BB5j7fI9Q/q5/VHISLq2M JCzg== X-Gm-Message-State: AMCzsaX5WL/DQJsyTK/hBQrPdIceok+KzvXhfOJnyVIPmA86prPomg6I WOEpK2ZC8HxshiH3tcnV/HBLIKLRpRv9J/Rmaig= X-Google-Smtp-Source: ABhQp+QINkmM7nTQyQ6Ay3LYjsnZe81s35pDMvaFMUwPp8BuZoCrg6jvg7Zih8+IYHoewVnIm5tM9Ybq9Ttkt9hXisU= X-Received: by 10.157.91.61 with SMTP id x58mr5688346oth.89.1508127332130; Sun, 15 Oct 2017 21:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 21:15:31 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Martin Thomson Date: Mon, 16 Oct 2017 15:15:31 +1100 Message-ID: To: Andy Green Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 04:15:34 -0000 On Mon, Oct 16, 2017 at 3:06 PM, Andy Green wrote: > What you are saying will save time I already assume is "for free" since it > happens during the time the HTML is fetched. Assuming that you need to some HTML, that will take a round trip, but that is concurrent with learning that the server supports websockets. After that, you should be able to CONNECT and send any frames at the same time: C: SETTINGS C: GET /index.html S: SETTINGS <-- I support :protocol S: 200 + DATA C: CONNECT + ws hs + DATA <-- client's first WS frames S: 200 + ws hs + DATA <-- server's first WS frames Still only two round trips. Were you concerned that the client needs to learn that the server supports websockets and not just :protocol? From nobody Sun Oct 15 21:44:29 2017 Return-Path: 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 15FC1134211 for ; Sun, 15 Oct 2017 21:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 N3Xi4mpkFszX for ; Sun, 15 Oct 2017 21:44:26 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C475F13420F for ; Sun, 15 Oct 2017 21:44:26 -0700 (PDT) To: Martin Thomson Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Andy Green Message-ID: Date: Mon, 16 Oct 2017 12:44:07 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 04:44:28 -0000 On 10/16/2017 12:15 PM, Martin Thomson wrote: > On Mon, Oct 16, 2017 at 3:06 PM, Andy Green wrote: >> What you are saying will save time I already assume is "for free" since it >> happens during the time the HTML is fetched. > > Assuming that you need to some HTML, that will take a round trip, but > that is concurrent with learning that the server supports websockets. > After that, you should be able to CONNECT and send any frames at the > same time: > > C: SETTINGS > C: GET /index.html > S: SETTINGS <-- I support :protocol > S: 200 + DATA > C: CONNECT + ws hs + DATA <-- client's first WS frames Well, you can't pipeline all those. The way ws works the client proposes one or more protocols and extensions. The server looks at what was sent and picks one protocol and zero or more extensions... > S: 200 + ws hs + DATA <-- server's first WS frames ...only after receiving the server's decision in the final ws hs headers, can the client send any ws data, because until then he doesn't know the disposition of the ws subprotocol or extensions for the stream. You can probably pipeline the CONNECT + ws handshake though, Patrick shows them sequentially and I didn't think about it myself. > Still only two round trips. - SETTINGS - SETTINGS - GET /index.html - 200 HEADERS + DATA - :method CONNECT - DATA ws handshake - 200 HEADERS - DATA ws handshake final - DATA... - DATA ... - DATA... With the part of the pipelining that is legal for ws, two round trips before the client can start to send data and 1.5 before the server can send data... if it's true then you're right it's not so bad. > Were you concerned that the client needs to learn that the server > supports websockets and not just :protocol? No I just followed Patrick's sequencing; he shows them serialized. But you're right at least the CONNECT + ws handshake can probably be pipelined. That's also going to be a variation from normal h2 HEADERS flow if I understood it, on one stream there will be END_HEADERs coming twice (for the CONNECT and the ws handshake separately) Anyway you are right, it makes any difference with PUSH_PROMISE probably not worth the effort. -Andy From nobody Sun Oct 15 22:21:50 2017 Return-Path: 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 24274126B6D for ; Sun, 15 Oct 2017 22:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 3ivSLQrwvlVJ for ; Sun, 15 Oct 2017 22:21:47 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 E135D134239 for ; Sun, 15 Oct 2017 22:21:46 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id v132so23423842oie.1 for ; Sun, 15 Oct 2017 22:21:46 -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=WQJuCpUyoyCYa/ca10K3EbQSXwXzp2OAc168xhHEHMo=; b=DJRbmP27lhWZa/6u03K2KhpHs9r0UY7gwk+ESXjogekAGRzLR1br2KkngXWLf1vLzy a/YIY04m0FOAwF58IIQYUdnrj814zT8thIDMk5f9UaopW+KDGvceR99WaAlzQpMmDB8r LgoTtHtQ3FCK16Kl/e2zbJlB2ZvK3L+cZMSmVQKz4llhzwnp01htx04GrRplILenZvOf bIiN04J1RcjVUPXcTYdxeaQeAizlhEWEeoEhQn1yXl68HQ7+p+pt1SC0LlvLSSEjLUCh O2ioJk2vK3DDTO9JMy4jkKL/ita2ear1paEgDY5NVvoZgbbKY68TcbnHDHkZJrfQ0LN9 M0Uw== 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=WQJuCpUyoyCYa/ca10K3EbQSXwXzp2OAc168xhHEHMo=; b=SaeGv5PP15XS3ykCGxdEMp0G/K6HiPKwxffCeyYrpm7BV7pyTSLkxNVhzzGMNzUQZg 61H4/2qswWlWowJ6Z17No1oh3yFvWSO30lenPxnO726ghIyYDVoVKw0TaJIxdcqfHp1g ZUb3px1mjgT4AgoA0Kel5FrZ1h8M+nzi20CGFjW2/3cyqCH3FRtmXpDq9J7tZgK6w4Cs hRjQAAKZPbWnAfOV4fVYt9YAj1drb3ox9b/XxV6Bv/rIB1SktzpC087qo48MdoNHTeeR 5V0Iabcrdnvl59XEVebKNki+/Vwxt4p29MSeCpxfTPAGr5GV5quHFWeN2cZNsA3eF7UY +8+Q== X-Gm-Message-State: AMCzsaVbTUyyWFcMyOsxB1+PHd8H35X7p0j5Xq4DFaZ3tbbjCyNBsJRY slEj0PuvIfvg9diqt8GkHdrAaKXRFcmbJ3Vk805OwQ== X-Google-Smtp-Source: ABhQp+Sk71Zs0sIMDzPPY9vxcaPUWO5zfN/Ov79BRlCxvNxlWTK3fEZTkOYSpFgwQucKepqhyoWzufbSjnZ3lmBIvds= X-Received: by 10.202.217.197 with SMTP id q188mr4034510oig.83.1508131306189; Sun, 15 Oct 2017 22:21:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 22:21:45 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Martin Thomson Date: Mon, 16 Oct 2017 16:21:45 +1100 Message-ID: To: Andy Green Cc: Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 05:21:48 -0000 On Mon, Oct 16, 2017 at 3:44 PM, Andy Green wrote: > Well, you can't pipeline all those. The way ws works the client proposes > one or more protocols and extensions. The server looks at what was sent and > picks one protocol and zero or more extensions... True, I was sort of assuming that you only had one option. If you have two, you could create a CONNECT for both and send the data twice. It's a multiplexed protocol after all. You would have to avoid non-idemponent actions, of course. From nobody Mon Oct 16 01:34:50 2017 Return-Path: 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 109A013448A for ; Mon, 16 Oct 2017 01:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 6kBtPlBPjN4n for ; Mon, 16 Oct 2017 01:34:46 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 2B7AD13448C for ; Mon, 16 Oct 2017 01:34:46 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id q132so638584wmd.2 for ; Mon, 16 Oct 2017 01:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JePazUvDQ2/L2ptWWso+YJtPjqnTRByc1unEVDPdJ2Y=; b=TwWuHd3hHFKpoDHTTOpQITu8/Km57CvG6wA4u505+NEb14V4jE65VMQncAbpAicAa+ vsSOxrcbwXgQBRTYHwIMYPcGJ2WIfGhGUtqQ2aLnoAyzvZEvinBFqTcpx67wWui073Cc FjL2H11Vqit+mS/IK3hQAkQ1euAcEGFze//5BlRH7ZaFGN6F2kAn7L9yMCTOEmqJ7vnf y38SP3lMMrqYtdZl3coQ2ulbKf3RbySMJI4+aZ6glvcU5btaQ6uYUWQtREoTLT1ot6yj w6yOAByXpfJ7oO1uwq0kbfT46WaO16vfbWF4OwwtCTyicjaeW+kbmzk+34lspwYu+q/2 eWhg== X-Gm-Message-State: AMCzsaXzs8oYvhF75QM3LaqkLYOqEbmUAatmex2TVE4llurQRJaKLT+j zGwtUuPZVJwNuTuNuTM8jcSJAWgD41mncnDgK0g= X-Google-Smtp-Source: AOwi7QDUGp4RmPrIvCRjqIRvzdE80BRX51p0OCw4O3rz6kto0DF2NCjNE4/jeuJYXsTpIdVAWsDk35IQAOvTy1qGg34= X-Received: by 10.223.134.154 with SMTP id 26mr8178377wrx.137.1508142884457; Mon, 16 Oct 2017 01:34:44 -0700 (PDT) MIME-Version: 1.0 References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> In-Reply-To: From: Jesse Wilson Date: Mon, 16 Oct 2017 08:34:32 +0000 Message-ID: To: Martin Thomson Cc: Andy Green , Cory Benfield , HTTP Working Group , Patrick McManus , Patrick McManus , hybi Content-Type: multipart/alternative; boundary="001a1146c57ee616a8055ba5e0e4" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 08:34:48 -0000 --001a1146c57ee616a8055ba5e0e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this proposal is a nice shortcut to getting the benefits of websockets on HTTP/2 without redesigning much. It=E2=80=99s something we co= uld probably add to OkHttp and MockWebServer in just a few days. There=E2=80=99s a policy question on what clients should do when a websocke= t is the first request to a target host. We can build an HTTP/2 connection and then hope to layer websockets on top, or build a bare websockets connection directly and forgo HTTP/2 multiplexing. Browsers might choose to persist settings to inform this decision. Or it would be handy to hint this in the ALPN protocols, though that would require the TLS layer to be aware of this setting! It=E2=80=99s worth explaining what should happen if a naughty client doesn= =E2=80=99t attempt a websocket upgrade within the DATA frames of a stream established for that purpose. In particular, a na=C3=AFve webserver might honor any HTT= P/1 request here; that seems like a potential attack vector. Suppose I send this: GET /admin HTTP/1.1 host: localhost Can I can trick a server into treating my request as originating from localhost? The HTTP/2 layer will have already routed the authority for this request but an attacker could contradict that! Nice to see a websockets and HTTP/2 proposal. Thanks! =E2=80=93 Jesse --001a1146c57ee616a8055ba5e0e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this proposal is a nice shortcut to getting the benefits of websock= ets on HTTP/2 without redesigning much. It=E2=80=99s something we could pro= bably add to OkHttp and MockWebServer in just a few days.

There=E2=80=99s a policy question on what clients should do when a websoc= ket is the first request to a target host. We can build an HTTP/2 connectio= n and then hope to layer websockets on top, or build a bare websockets conn= ection directly and forgo HTTP/2 multiplexing. Browsers might choose to per= sist settings to inform this decision. Or it would be handy to hint this in= the ALPN protocols, though that would require the TLS layer to be aware of= this setting!

It=E2=80=99s worth explaining what = should happen if a naughty client doesn=E2=80=99t attempt a websocket upgra= de within the DATA frames of a stream established for that purpose. In part= icular, a na=C3=AFve webserver might honor any HTTP/1 request here; that se= ems like a potential attack vector. Suppose I send this:

=C2=A0 GET /admin HTTP/1.1
=C2=A0 host: localhost

Can I can trick a server in= to treating my request as originating from localhost? The HTTP/2 layer will= have already routed the authority for this request but an attacker could c= ontradict that!

Nice to see a websockets an= d HTTP/2 proposal. Thanks!

=E2=80=93 Jesse<= /div>

--001a1146c57ee616a8055ba5e0e4-- From nobody Mon Oct 16 05:16:01 2017 Return-Path: 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 B8A6013431F for ; Mon, 16 Oct 2017 05:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 URCPwBkFF2Py for ; Mon, 16 Oct 2017 05:15:58 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 331D6132D49 for ; Mon, 16 Oct 2017 05:15:58 -0700 (PDT) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3273E3A0A6 for ; Mon, 16 Oct 2017 08:15:57 -0400 (EDT) Received: by mail-lf0-f42.google.com with SMTP id d10so16742786lfg.11 for ; Mon, 16 Oct 2017 05:15:57 -0700 (PDT) X-Gm-Message-State: AMCzsaXv6I9+HgItvUmVBMe1GaO5IU2BkoDyH+deYxQ7IzczO52Nzyf2 5ruh+yxXbLEEui1AH0OAFeb5x70NzJMXb4hf6UM= X-Google-Smtp-Source: ABhQp+S48xl9OaLvr06Jsmk7PEhZ5LdXX/HDzi16R5i/5U+6mhagAEzFFl6X2JQSDBh5IhmYePtwjKNr7Y2HToDuTPc= X-Received: by 10.25.142.13 with SMTP id q13mr2917824lfd.217.1508156155908; Mon, 16 Oct 2017 05:15:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Mon, 16 Oct 2017 05:15:54 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Patrick McManus Date: Mon, 16 Oct 2017 08:15:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andy Green Cc: Martin Thomson , Patrick McManus , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: multipart/alternative; boundary="f403045f5312f05c2c055ba8f717" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 12:16:00 -0000 --f403045f5312f05c2c055ba8f717 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 16, 2017 at 12:44 AM, Andy Green wrote: > > You can probably pipeline the CONNECT + ws handshake though, Patrick shows > them sequentially and I didn't think about it myself. > > right. The example is just for clarity and cannot show all expressions of h2 flows. CONNECT + DATA before the response headers is pretty much the h2 analog of TCP Fast Open. The devil is in the details.. That's a general CONNECT + DATA issue not limited to the protocol upgrade described here so I don't think its worth discussion in a websockets rfc. I think the path to success here hinges on a very tight scoping of work and therefore optimizing handshake latency is a non-goal of this effort. > Still only two round trips. >> > > - SETTINGS - SETTINGS > - GET /index.html > - 200 HEADERS + DATA > > - :method CONNECT > - DATA ws handshake > - 200 HEADERS > - DATA ws handshake final > - DATA... > > - DATA ... - DATA... > > With the part of the pipelining that is legal for ws, two round trips > before the client can start to send data and 1.5 before the server can send > data... if it's true then you're right it's not so bad. > > Were you concerned that the client needs to learn that the server >> supports websockets and not just :protocol? >> > > No I just followed Patrick's sequencing; he shows them serialized. But > you're right at least the CONNECT + ws handshake can probably be pipelined. > > That's also going to be a variation from normal h2 HEADERS flow if I > understood it, on one stream there will be END_HEADERs coming twice (for > the CONNECT and the ws handshake separately) > > Anyway you are right, it makes any difference with PUSH_PROMISE probably > not worth the effort. > > -Andy > --f403045f5312f05c2c055ba8f717 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <andy@warmcat.com><= /span> wrote:

You can probably pipeline the CONNECT + ws handshake though, Patrick shows = them sequentially and I didn't think about it myself.<= br>

right. The example is just for = clarity and cannot show all expressions of h2 flows.

CONNECT + DATA before the response headers is pretty much the h2 analog= of TCP Fast Open. The devil is in the details.. That's a general CONNE= CT + DATA issue not limited to the protocol upgrade described here so I don= 't think its worth discussion in a websockets rfc.

=
I think the path to success here hinges on a very tight scoping of wor= k and therefore optimizing handshake latency is a non-goal of this effort.<= /div>

=C2=A0
Still only two round trips.

 =C2=A0- SETTINGS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 - SETTINGS
=C2=A0- GET /index.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 200 HEADERS= + DATA

=C2=A0- :method CONNECT
 =C2=A0- DATA ws handshake
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 200 HEADER= S
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DATA ws ha= ndshake final
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DATA...
=C2=A0- DATA ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DATA...
With the part of the pipelining that is legal for ws, two round trips befor= e the client can start to send data and 1.5 before the server can send data= ... if it's true then you're right it's not so bad.

Were you concerned that the client needs to learn that the server
supports websockets and not just :protocol?

 No I just followed Patrick's sequencing; he shows them serialized.=C2= =A0 But you're right at least the CONNECT + ws handshake can probably b= e pipelined.

That's also going to be a variation from normal h2 HEADERS flow if I un= derstood it, on one stream there will be END_HEADERs coming twice (for the = CONNECT and the ws handshake separately)

Anyway you are right, it makes any difference with PUSH_PROMISE probably no= t worth the effort.

-Andy

--f403045f5312f05c2c055ba8f717-- From nobody Mon Oct 16 08:33:09 2017 Return-Path: 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 BFCA6133049 for ; Mon, 16 Oct 2017 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZQ_Tz2C9Op62 for ; Mon, 16 Oct 2017 08:33:05 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB32133055 for ; Mon, 16 Oct 2017 08:33:04 -0700 (PDT) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v9GFX01A003788; Mon, 16 Oct 2017 16:33:00 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0319.002; Mon, 16 Oct 2017 16:33:00 +0100 From: Lucas Pardue To: Patrick McManus , HTTP Working Group , hybi Thread-Topic: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt Thread-Index: AQHTRcA2rKps2szY4U+GtuV6F2532KLmlgGb Date: Mon, 16 Oct 2017 15:33:00 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BA6F15A@bgb01xud1012> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23398.007 x-tm-as-result: No--14.463700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BA6F15Abgb01xud1012_" MIME-Version: 1.0 Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 15:33:08 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BA6F15Abgb01xud1012_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Patrick, Interesting, thanks. Some comments: 1) In section 3: A sender MUST NOT send a ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. What should the client do in such a situation? It seems overzealous to call= this a protocol error, maybe we could just say that since the initial/default is 0, a change to 1 is sticky and t= herefore the client MUST ignore any ENABLE_CONNECT_PROTOCOL with a value of 0. A different way to look at this = is that as the document stands, sending ENABLE_CONNECT_PROTOCOL with a value of 0 is meaningless. 1) In section 7: The use of a pseudo-header is something that is connection specific and HTTP/2 does not ever allow to be created outside of the protocol stack. I think I understand the intent of this paragraph but I'm not sure its qual= ified by anything. Is there something that RFC 7540 says on the matter, or = is this based on your observation of H2 implementation stacks? 2) In section 8 the error code 0x8 is reserved, however the HTTP/2 Settings= registry indicates 0x7 is free. Is this skip over intended? Cheers Lucas ________________________________ From: Patrick McManus [mcmanus@ducksong.com] Sent: 15 October 2017 15:12 To: HTTP Working Group; hybi Subject: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websock= ets-00.txt FYI - also see https://github.com/mcmanus/draft-h2ws/blob/master/README.md Comments, expressions of interest, etc are very welcome. ---------- Forwarded message ---------- From: > Date: Sun, Oct 15, 2017 at 10:08 AM Subject: New Version Notification for draft-mcmanus-httpbis-h2-websockets-0= 0.txt To: Patrick McManus > A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt has been successfully submitted by Patrick McManus and posted to the IETF repository. Name: draft-mcmanus-httpbis-h2-websockets Revision: 00 Title: Bootstrapping WebSockets with HTTP/2 Document date: 2017-10-15 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-= h2-websockets-00.txt Status: https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-w= ebsockets/ Htmlized: https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websoc= kets-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis= -h2-websockets-00 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_7CF7F94CB496BF4FAB1676F375F9666A3BA6F15Abgb01xud1012_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Patrick,

Interesting, thanks.

Some comments:

1) In section 3:

A sender MUST NOT send a ENABLE_CONNEC=
T_PROTOCOL parameter with the=0A=
value of 0 after previously sending a value of 1.

What should the =
client do in such a situation? It seems overzealous to call this a protocol=
 error, maybe we could 
just say that si=
nce the initial/default is 0, a change to 1 is sticky and therefore the cli=
ent MUST ignore any 
ENABLE_CONNECT_P=
ROTOCOL with a value of 0. A different way to look at this is that as the d=
ocument stands,
sending ENABLE_C=
ONNECT_PROTOCOL with a value of 0 is meaningless.

1) In section 7:

The use of a pseudo-header is somethin=
g that is connection=0A=
specific and HTTP/2 does not ever allow to be created outside of=0A=
the protocol stack.

I think I understand the intent of=
 this paragraph but I'm not sure its qualified by anything. Is there someth=
ing that RFC 7540 says on the matter, or is this based on your observation =
of H2 implementation stacks?

2) In section 8 the err=
or code 0x8 is reserved, however the HTTP/2 Settings registry indicates 0x7=
 is free. Is this skip over intended?

Cheers


From: Patrick McManus [mcmanus@ducksong.c=
om]

Sent: 15 October 2017 15:12

To: HTTP Working Group; hybi

Subject: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-=
websockets-00.txt


















Comments, expressions of interest, etc are very welcome.














---------- Forwarded message ----------

From: <internet-drafts@ietf.org>

Date: Sun, Oct 15, 2017 at 10:08 AM

Subject: New Version Notification for draft-mcmanus-httpbis-h2-websockets-0=
0.txt

To: Patrick McManus <mcmanus@ducksong.com>







A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt

has been successfully submitted by Patrick McManus and posted to the

IETF repository.



Name:           draft-mcmanus-httpbis-h2-websockets

Revision:       00

Title:          Bootstrapping WebSockets with HTTP=
/2

Document date:  2017-10-15

Group:          Individual Submission

Pages:          7

URL:            
https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-web=
sockets-00.txt

Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-=
websockets/

Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets=
-00

Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-h=
ttpbis-h2-websockets-00





Abstract:

   This document defines a mechanism for running the WebSocket Pr=
otocol

   [RFC6455] over a single stream of an HTTP/2 connection.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



The IETF Secretariat
--_000_7CF7F94CB496BF4FAB1676F375F9666A3BA6F15Abgb01xud1012_-- From nobody Mon Oct 16 10:13:26 2017 Return-Path: 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 CEEDF13319E for ; Mon, 16 Oct 2017 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 qZW3PVsJIEQo for ; Mon, 16 Oct 2017 10:13:21 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0498133072 for ; Mon, 16 Oct 2017 10:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KiOuKTWmoaaCGAoSOrub8iPZzW0RM4dhSqNDOVMkxrk=; b=eyz8MPzaXqC4wu9qOi6ouD634uUEVSVG3Jtj9qRYj78jdw5XHgd7WyKWUDnN/albCgRjm/TRagIxz+/xART68nUfYIu1R5euYeWTExAStJvHNOPgZdIzZw1S/WOr7nXRymLKcrusGO51jOTBLK96n9/H+pSYqSMY2Ty71GVglFY= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0800.namprd21.prod.outlook.com (10.175.142.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Mon, 16 Oct 2017 17:13:20 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0156.003; Mon, 16 Oct 2017 17:13:19 +0000 From: Mike Bishop To: Patrick McManus , Andy Green CC: Martin Thomson , hybi , "Cory Benfield" , Patrick McManus , "HTTP Working Group" Thread-Topic: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt Thread-Index: AQHTRnkXSa3fJMYEE0KGC67TZNNyA6LmtAUg Date: Mon, 16 Oct 2017 17:13:19 +0000 Message-ID: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2::659] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0800; 6:1+F9+/G4TGSw9SAuYF2e7atnFoUdaeT3Mfa3IkUeAfjCO3mdLs/0ng4OgKqmJIqnsES6sgHL33+DkF8OpCikRSw24zJoFrX+gw8OfE4+XWgvqvwZkos38e2AdxRycL6dLP6V5gg0Zb4jc3PMLofdqreRM90sgRnXBNZXu+ir7KNyV6nUgr/7GPW+6zmURrpVy7p5rcVxskAME1w5gppfHvbyqoO/jBaSk6EPylcJ0kwv1WFYkrL2OBpNhMVX54b3fYuBfVgNsO8N+DoobX9q++/pDqWZRQpKsPBL+Wwf6PxTqbwax+oLebsHxla0vyIu7GpHhKe5BgezMND5rM8rXVQfDlP3/QdkI/Q9IslaboA=; 5:4wjaeiXRI/ZlOBK6IVNOlVZh7nxkjHtIyAlLssiK0x62Ax3hVJnPWOp/mZrK62HL/rMcimTitN9dYfOgQsqu7C0QawjcCIW0Wis/tgQgWThSZzB8PvalsxhuoWmHFOaCS6IH9yMay6haxhDRTVyGTZ3Cci7upDJCuZUA0VBB3Jc=; 24:iNTgj8Wl/Xt4RRQ+byUK5an32u1QqJeQZK+FtR0Y6ZOpPYvqx24Lj1nC1D9fZw7khhkei3b1CATdhgModSGyKXnzMz9zBzJi0uSsphQOnGA=; 7:CvypU6jhIxF4E0Qe7xBuQzbGTyRvX+1ZYSEh7J4UN6b/wUxonS93xpKdvGQT11GxfKsKV/0LPUwXG+H2SduW7Nvb5v5XwUXbB1Tt1JHPVQwqlWYsBVB/YQqnntPnh/qDJIX/U10cBUsoGQU58h7QmI9WLwGq24g5nZzaA8Iw72Et4a8eR/pDGf+6AvOROp9Guz/WPCIJrOQC6LHYS9HvfUmM7iGQ+v6a3J0r1jxmcDycVUL7+MfPDrzf6hM8ecT/ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8f65d9f1-1820-40ae-4de0-08d514b932fe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603219)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0800; x-ms-traffictypediagnostic: MWHPR21MB0800: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(21532816269658)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0800; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0800; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(47760400005)(24454002)(199003)(377454003)(189002)(19609705001)(86612001)(8990500004)(6436002)(8936002)(7736002)(15650500001)(77096006)(101416001)(10090500001)(347745004)(106356001)(72206003)(105586002)(5660300001)(25786009)(86362001)(4326008)(39060400002)(74316002)(9686003)(2420400007)(478600001)(99286003)(10290500003)(55016002)(54896002)(97736004)(6506006)(6306002)(68736007)(7696004)(53936002)(229853002)(33656002)(236005)(3660700001)(189998001)(2900100001)(3280700002)(22452003)(7110500001)(230783001)(8676002)(2950100002)(81156014)(81166006)(10710500007)(93886005)(53546010)(2906002)(54356999)(76176999)(50986999)(790700001)(6246003)(54906003)(6116002)(110136005)(316002)(14454004)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0800; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141A705D0182DA51B934280874F0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f65d9f1-1820-40ae-4de0-08d514b932fe X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 17:13:19.7743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0800 Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 17:13:24 -0000 --_000_MWHPR21MB0141A705D0182DA51B934280874F0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2VuZXJhbGl6aW5nIENPTk5FQ1QgdG8gYWxsb3cgeW91IHRvIHR1bm5lbCBwcm90b2NvbHMgb3Ro ZXIgdGhhbiBUQ1Ag4oCTIG9yIHJhdGhlciwgdG8gZXhwbGljaXRseSBzdGF0ZSB3aGF0IHByb3Rv Y29sIHRoZSBvdGhlciBzaWRlIHNob3VsZCBiZSBleHBlY3RpbmcgdGhlIFRDUCBjb25uZWN0aW9u IHRvIHNwZWFrIOKAkyBpcyBhIG5lYXQgYXBwcm9hY2guICBTbyBmaXJzdCBvZmYsIGt1ZG9zIQ0K DQpJZiB5b3Ugc2F5IHlvdeKAmXJlIHVwZ3JhZGluZyB0byBXZWJTb2NrZXRzLCB0aGVuIEnigJlk IGV4cGVjdCBpdCB0byBhY3R1YWxseSB1cGdyYWRlIHN0cmFpZ2h0IHRvIFdlYlNvY2tldHMsIG5v dCBhbiBIVFRQLzEuMSByZXF1ZXN0IHdoaWNoIGlzIGV4cGVjdGVkIHRvIHRoZW4gdXBncmFkZSB0 byBXZWJTb2NrZXRzLiAgSSB1bmRlcnN0YW5kIHRoYXQgd291bGQgZW50YWlsIHB1dHRpbmcgYWxs IHRoZSBXZWJTb2NrZXQgbmVnb3RpYXRpb24gaGVhZGVycyBvbiB0aGUgQ09OTkVDVCBpdHNlbGYs IGV0Yy4gYW5kIEnigJltIHN5bXBhdGhldGljIHRvIHRoZSBhcmd1bWVudCB0aGF0IGl0IGlzIGEg bGFyZ2VyIGNoYW5nZSB0aGF0IG1heSBwcm9kdWNlIGEgcm9hZGJ1bXAuICBCdXQgeW914oCZcmUg bWFraW5nIGEgY29tbWl0bWVudCBhdCB0aGUgSFRUUC8yIGxheWVyIHRoYXQgYWN0dWFsbHkgbWVh bnMgbm90aGluZyAo4oCcd3Nz4oCdIHNjaGVtZSwg4oCcd2Vic29ja2V04oCdIDpwcm90b2NvbCku DQoNCkdpdmVuIHRoYXQgeW914oCZcmUgZG9pbmcgdGhlIGZ1bGwgVXBncmFkZS10by1XZWJTb2Nr ZXRzIGRhbmNlIGluc2lkZSB0aGUgdHVubmVsZWQgY29ubmVjdGlvbiwgd2h5IGRvbuKAmXQgeW91 IGp1c3Qgc2F5IHRoYXQgeW914oCZcmUgQ09OTkVDVGluZyB0byBhbiBIVFRQLzEuMSB0dW5uZWw/ ICBUaGF04oCZcyB0aGVuIHRyZWF0ZWQgYXMgSFRUUC8xLjEgb3ZlciBUQ1AsIHdoaWNoIGlzIGZ1 bGx5IGFsbG93ZWQgdG8gZG8gVXBncmFkZSBpdHNlbGYuICBJZiB5b3XigJlyZSBzdXJlIHRoYXTi gJlzIHRoZSBwYXRoIHlvdSB3YW50LCB0aGVuIHNpbXBseSBzYXkgaW4gdGhlIEhUVFAvMiBsYXll ciB0aGF0IHlvdeKAmXJlIGRvaW5nIEhUVFAvMS4xIGluc2lkZSB0aGUgc3RyZWFtLiAgSW5jaWRl bnRhbGx5LCB0aGF0IG1pZ2h0IGJlIGEgbmljZSBhbHRlcm5hdGl2ZSBmb3IgZGVhbGluZyB3aXRo IEhUVFBfMV8xX1JFUVVJUkVEIHJlc3BvbnNlcywgdG9vIQ0KDQpGcm9tOiBQYXRyaWNrIE1jTWFu dXMgW21haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbV0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAx NiwgMjAxNyA1OjE2IEFNDQpUbzogQW5keSBHcmVlbiA8YW5keUB3YXJtY2F0LmNvbT4NCkNjOiBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgUGF0cmljayBNY01hbnVz IDxwbWNtYW51c0Btb3ppbGxhLmNvbT47IGh5YmkgPGh5YmlAaWV0Zi5vcmc+OyBDb3J5IEJlbmZp ZWxkIDxjb3J5QGx1a2FzYS5jby51az47IFBhdHJpY2sgTWNNYW51cyA8bWNtYW51c0BkdWNrc29u Zy5jb20+OyBIVFRQIFdvcmtpbmcgR3JvdXAgPGlldGYtaHR0cC13Z0B3My5vcmc+DQpTdWJqZWN0 OiBSZTogW2h5YmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWNtYW51cy1o dHRwYmlzLWgyLXdlYnNvY2tldHMtMDAudHh0DQoNCg0KDQpPbiBNb24sIE9jdCAxNiwgMjAxNyBh dCAxMjo0NCBBTSwgQW5keSBHcmVlbiA8YW5keUB3YXJtY2F0LmNvbTxtYWlsdG86YW5keUB3YXJt Y2F0LmNvbT4+IHdyb3RlOg0KDQpZb3UgY2FuIHByb2JhYmx5IHBpcGVsaW5lIHRoZSBDT05ORUNU ICsgd3MgaGFuZHNoYWtlIHRob3VnaCwgUGF0cmljayBzaG93cyB0aGVtIHNlcXVlbnRpYWxseSBh bmQgSSBkaWRuJ3QgdGhpbmsgYWJvdXQgaXQgbXlzZWxmLg0KDQpyaWdodC4gVGhlIGV4YW1wbGUg aXMganVzdCBmb3IgY2xhcml0eSBhbmQgY2Fubm90IHNob3cgYWxsIGV4cHJlc3Npb25zIG9mIGgy IGZsb3dzLg0KDQpDT05ORUNUICsgREFUQSBiZWZvcmUgdGhlIHJlc3BvbnNlIGhlYWRlcnMgaXMg cHJldHR5IG11Y2ggdGhlIGgyIGFuYWxvZyBvZiBUQ1AgRmFzdCBPcGVuLiBUaGUgZGV2aWwgaXMg aW4gdGhlIGRldGFpbHMuLiBUaGF0J3MgYSBnZW5lcmFsIENPTk5FQ1QgKyBEQVRBIGlzc3VlIG5v dCBsaW1pdGVkIHRvIHRoZSBwcm90b2NvbCB1cGdyYWRlIGRlc2NyaWJlZCBoZXJlIHNvIEkgZG9u J3QgdGhpbmsgaXRzIHdvcnRoIGRpc2N1c3Npb24gaW4gYSB3ZWJzb2NrZXRzIHJmYy4NCg0KSSB0 aGluayB0aGUgcGF0aCB0byBzdWNjZXNzIGhlcmUgaGluZ2VzIG9uIGEgdmVyeSB0aWdodCBzY29w aW5nIG9mIHdvcmsgYW5kIHRoZXJlZm9yZSBvcHRpbWl6aW5nIGhhbmRzaGFrZSBsYXRlbmN5IGlz IGEgbm9uLWdvYWwgb2YgdGhpcyBlZmZvcnQuDQoNCg0KU3RpbGwgb25seSB0d28gcm91bmQgdHJp cHMuDQoNCiAtIFNFVFRJTkdTICAgICAgICAgICAgICAgICAgICAgIC0gU0VUVElOR1MNCiAtIEdF VCAvaW5kZXguaHRtbA0KICAgICAgICAgICAgICAgICAtIDIwMCBIRUFERVJTICsgREFUQQ0KDQog LSA6bWV0aG9kIENPTk5FQ1QNCiAtIERBVEEgd3MgaGFuZHNoYWtlDQogICAgICAgICAgICAgICAg ICAtIDIwMCBIRUFERVJTDQogICAgICAgICAgICAgICAgICAtIERBVEEgd3MgaGFuZHNoYWtlIGZp bmFsDQogICAgICAgICAgICAgICAgICAtIERBVEEuLi4NCg0KIC0gREFUQSAuLi4gICAgICAgICAg ICAgLSBEQVRBLi4uDQoNCldpdGggdGhlIHBhcnQgb2YgdGhlIHBpcGVsaW5pbmcgdGhhdCBpcyBs ZWdhbCBmb3Igd3MsIHR3byByb3VuZCB0cmlwcyBiZWZvcmUgdGhlIGNsaWVudCBjYW4gc3RhcnQg dG8gc2VuZCBkYXRhIGFuZCAxLjUgYmVmb3JlIHRoZSBzZXJ2ZXIgY2FuIHNlbmQgZGF0YS4uLiBp ZiBpdCdzIHRydWUgdGhlbiB5b3UncmUgcmlnaHQgaXQncyBub3Qgc28gYmFkLg0KV2VyZSB5b3Ug Y29uY2VybmVkIHRoYXQgdGhlIGNsaWVudCBuZWVkcyB0byBsZWFybiB0aGF0IHRoZSBzZXJ2ZXIN CnN1cHBvcnRzIHdlYnNvY2tldHMgYW5kIG5vdCBqdXN0IDpwcm90b2NvbD8NCg0KTm8gSSBqdXN0 IGZvbGxvd2VkIFBhdHJpY2sncyBzZXF1ZW5jaW5nOyBoZSBzaG93cyB0aGVtIHNlcmlhbGl6ZWQu ICBCdXQgeW91J3JlIHJpZ2h0IGF0IGxlYXN0IHRoZSBDT05ORUNUICsgd3MgaGFuZHNoYWtlIGNh biBwcm9iYWJseSBiZSBwaXBlbGluZWQuDQoNClRoYXQncyBhbHNvIGdvaW5nIHRvIGJlIGEgdmFy aWF0aW9uIGZyb20gbm9ybWFsIGgyIEhFQURFUlMgZmxvdyBpZiBJIHVuZGVyc3Rvb2QgaXQsIG9u IG9uZSBzdHJlYW0gdGhlcmUgd2lsbCBiZSBFTkRfSEVBREVScyBjb21pbmcgdHdpY2UgKGZvciB0 aGUgQ09OTkVDVCBhbmQgdGhlIHdzIGhhbmRzaGFrZSBzZXBhcmF0ZWx5KQ0KDQpBbnl3YXkgeW91 IGFyZSByaWdodCwgaXQgbWFrZXMgYW55IGRpZmZlcmVuY2Ugd2l0aCBQVVNIX1BST01JU0UgcHJv YmFibHkgbm90IHdvcnRoIHRoZSBlZmZvcnQuDQoNCi1BbmR5DQoNCg== --_000_MWHPR21MB0141A705D0182DA51B934280874F0MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdlbmVyYWxpemluZyBDT05ORUNUIHRvIGFs bG93IHlvdSB0byB0dW5uZWwgcHJvdG9jb2xzIG90aGVyIHRoYW4gVENQIOKAkyBvciByYXRoZXIs IHRvIGV4cGxpY2l0bHkgc3RhdGUgd2hhdCBwcm90b2NvbCB0aGUgb3RoZXIgc2lkZSBzaG91bGQg YmUgZXhwZWN0aW5nIHRoZSBUQ1AgY29ubmVjdGlvbiB0byBzcGVhayDigJMgaXMgYSBuZWF0IGFw cHJvYWNoLiZuYnNwOyBTbyBmaXJzdCBvZmYsIGt1ZG9zITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB5b3Ugc2F5IHlvdeKAmXJlIHVwZ3JhZGluZyB0byBXZWJTb2NrZXRzLCB0aGVuIEnigJlk IGV4cGVjdCBpdCB0byBhY3R1YWxseSB1cGdyYWRlIHN0cmFpZ2h0IHRvIFdlYlNvY2tldHMsIG5v dCBhbiBIVFRQLzEuMSByZXF1ZXN0IHdoaWNoIGlzIGV4cGVjdGVkIHRvIHRoZW4gdXBncmFkZSB0 byBXZWJTb2NrZXRzLiZuYnNwOyBJIHVuZGVyc3RhbmQgdGhhdCB3b3VsZCBlbnRhaWwgcHV0dGlu ZyBhbGwgdGhlIFdlYlNvY2tldA0KIG5lZ290aWF0aW9uIGhlYWRlcnMgb24gdGhlIENPTk5FQ1Qg aXRzZWxmLCBldGMuIGFuZCBJ4oCZbSBzeW1wYXRoZXRpYyB0byB0aGUgYXJndW1lbnQgdGhhdCBp dCBpcyBhIGxhcmdlciBjaGFuZ2UgdGhhdCBtYXkgcHJvZHVjZSBhIHJvYWRidW1wLiZuYnNwOyBC dXQgeW914oCZcmUgbWFraW5nIGEgY29tbWl0bWVudCBhdCB0aGUgSFRUUC8yIGxheWVyIHRoYXQg YWN0dWFsbHkgbWVhbnMgbm90aGluZyAo4oCcd3Nz4oCdIHNjaGVtZSwg4oCcd2Vic29ja2V04oCd IDpwcm90b2NvbCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoYXQgeW914oCZcmUg ZG9pbmcgdGhlIGZ1bGwgVXBncmFkZS10by1XZWJTb2NrZXRzIGRhbmNlIGluc2lkZSB0aGUgdHVu bmVsZWQgY29ubmVjdGlvbiwgd2h5IGRvbuKAmXQgeW91IGp1c3Qgc2F5IHRoYXQgeW914oCZcmUg Q09OTkVDVGluZyB0byBhbiBIVFRQLzEuMSB0dW5uZWw/Jm5ic3A7IFRoYXTigJlzIHRoZW4gdHJl YXRlZCBhcyBIVFRQLzEuMSBvdmVyIFRDUCwgd2hpY2ggaXMgZnVsbHkgYWxsb3dlZCB0byBkbyBV cGdyYWRlDQogaXRzZWxmLiZuYnNwOyBJZiB5b3XigJlyZSBzdXJlIHRoYXTigJlzIHRoZSBwYXRo IHlvdSB3YW50LCB0aGVuIHNpbXBseSBzYXkgaW4gdGhlIEhUVFAvMiBsYXllciB0aGF0IHlvdeKA mXJlIGRvaW5nIEhUVFAvMS4xIGluc2lkZSB0aGUgc3RyZWFtLiZuYnNwOyBJbmNpZGVudGFsbHks IHRoYXQgbWlnaHQgYmUgYSBuaWNlIGFsdGVybmF0aXZlIGZvciBkZWFsaW5nIHdpdGggSFRUUF8x XzFfUkVRVUlSRUQgcmVzcG9uc2VzLCB0b28hPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBQYXRyaWNrIE1jTWFudXMgW21haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbV0gPGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAxNiwgMjAxNyA1OjE2IEFNPGJyPg0KPGI+ VG86PC9iPiBBbmR5IEdyZWVuICZsdDthbmR5QHdhcm1jYXQuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7IFBhdHJp Y2sgTWNNYW51cyAmbHQ7cG1jbWFudXNAbW96aWxsYS5jb20mZ3Q7OyBoeWJpICZsdDtoeWJpQGll dGYub3JnJmd0OzsgQ29yeSBCZW5maWVsZCAmbHQ7Y29yeUBsdWthc2EuY28udWsmZ3Q7OyBQYXRy aWNrIE1jTWFudXMgJmx0O21jbWFudXNAZHVja3NvbmcuY29tJmd0OzsgSFRUUCBXb3JraW5nIEdy b3VwICZsdDtpZXRmLWh0dHAtd2dAdzMub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W2h5YmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWNtYW51cy1odHRwYmlz LWgyLXdlYnNvY2tldHMtMDAudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAxNiwg MjAxNyBhdCAxMjo0NCBBTSwgQW5keSBHcmVlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAd2Fy bWNhdC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHdhcm1jYXQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpZb3UgY2FuIHByb2JhYmx5IHBpcGVsaW5lIHRo ZSBDT05ORUNUICYjNDM7IHdzIGhhbmRzaGFrZSB0aG91Z2gsIFBhdHJpY2sgc2hvd3MgdGhlbSBz ZXF1ZW50aWFsbHkgYW5kIEkgZGlkbid0IHRoaW5rIGFib3V0IGl0IG15c2VsZi48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJpZ2h0 LiBUaGUgZXhhbXBsZSBpcyBqdXN0IGZvciBjbGFyaXR5IGFuZCBjYW5ub3Qgc2hvdyBhbGwgZXhw cmVzc2lvbnMgb2YgaDIgZmxvd3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNPTk5FQ1QgJiM0MzsgREFUQSBiZWZvcmUgdGhlIHJlc3BvbnNl IGhlYWRlcnMgaXMgcHJldHR5IG11Y2ggdGhlIGgyIGFuYWxvZyBvZiBUQ1AgRmFzdCBPcGVuLiBU aGUgZGV2aWwgaXMgaW4gdGhlIGRldGFpbHMuLiBUaGF0J3MgYSBnZW5lcmFsIENPTk5FQ1QgJiM0 MzsgREFUQSBpc3N1ZSBub3QgbGltaXRlZCB0byB0aGUgcHJvdG9jb2wgdXBncmFkZSBkZXNjcmli ZWQgaGVyZSBzbyBJIGRvbid0IHRoaW5rIGl0cyB3b3J0aA0KIGRpc2N1c3Npb24gaW4gYSB3ZWJz b2NrZXRzIHJmYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB0aGluayB0aGUgcGF0aCB0byBzdWNjZXNzIGhlcmUgaGluZ2VzIG9uIGEgdmVy eSB0aWdodCBzY29waW5nIG9mIHdvcmsgYW5kIHRoZXJlZm9yZSBvcHRpbWl6aW5nIGhhbmRzaGFr ZSBsYXRlbmN5IGlzIGEgbm9uLWdvYWwgb2YgdGhpcyBlZmZvcnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN0aWxsIG9ubHkgdHdvIHJvdW5kIHRyaXBzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQombmJzcDstIFNFVFRJTkdTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIFNFVFRJTkdTPGJyPg0KJm5i c3A7LSBHRVQgL2luZGV4Lmh0bWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gMjAwIEhFQURFUlMgJiM0MzsgREFUQTxi cj4NCjxicj4NCiZuYnNwOy0gOm1ldGhvZCBDT05ORUNUPGJyPg0KJm5ic3A7LSBEQVRBIHdzIGhh bmRzaGFrZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IC0gMjAwIEhFQURFUlM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIERBVEEgd3MgaGFu ZHNoYWtlIGZpbmFsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBEQVRBLi4uPGJyPg0KPGJyPg0KJm5ic3A7LSBEQVRB IC4uLiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gREFU QS4uLjxicj4NCjxicj4NCldpdGggdGhlIHBhcnQgb2YgdGhlIHBpcGVsaW5pbmcgdGhhdCBpcyBs ZWdhbCBmb3Igd3MsIHR3byByb3VuZCB0cmlwcyBiZWZvcmUgdGhlIGNsaWVudCBjYW4gc3RhcnQg dG8gc2VuZCBkYXRhIGFuZCAxLjUgYmVmb3JlIHRoZSBzZXJ2ZXIgY2FuIHNlbmQgZGF0YS4uLiBp ZiBpdCdzIHRydWUgdGhlbiB5b3UncmUgcmlnaHQgaXQncyBub3Qgc28gYmFkLjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlcmUgeW91IGNvbmNlcm5l ZCB0aGF0IHRoZSBjbGllbnQgbmVlZHMgdG8gbGVhcm4gdGhhdCB0aGUgc2VydmVyPGJyPg0Kc3Vw cG9ydHMgd2Vic29ja2V0cyBhbmQgbm90IGp1c3QgOnByb3RvY29sPzxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KTm8gSSBqdXN0IGZvbGxv d2VkIFBhdHJpY2sncyBzZXF1ZW5jaW5nOyBoZSBzaG93cyB0aGVtIHNlcmlhbGl6ZWQuJm5ic3A7 IEJ1dCB5b3UncmUgcmlnaHQgYXQgbGVhc3QgdGhlIENPTk5FQ1QgJiM0Mzsgd3MgaGFuZHNoYWtl IGNhbiBwcm9iYWJseSBiZSBwaXBlbGluZWQuPGJyPg0KPGJyPg0KVGhhdCdzIGFsc28gZ29pbmcg dG8gYmUgYSB2YXJpYXRpb24gZnJvbSBub3JtYWwgaDIgSEVBREVSUyBmbG93IGlmIEkgdW5kZXJz dG9vZCBpdCwgb24gb25lIHN0cmVhbSB0aGVyZSB3aWxsIGJlIEVORF9IRUFERVJzIGNvbWluZyB0 d2ljZSAoZm9yIHRoZSBDT05ORUNUIGFuZCB0aGUgd3MgaGFuZHNoYWtlIHNlcGFyYXRlbHkpPGJy Pg0KPGJyPg0KQW55d2F5IHlvdSBhcmUgcmlnaHQsIGl0IG1ha2VzIGFueSBkaWZmZXJlbmNlIHdp dGggUFVTSF9QUk9NSVNFIHByb2JhYmx5IG5vdCB3b3J0aCB0aGUgZWZmb3J0LjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tQW5keTwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0141A705D0182DA51B934280874F0MWHPR21MB0141namp_-- From nobody Mon Oct 16 14:31:53 2017 Return-Path: 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 3B20213304B for ; Mon, 16 Oct 2017 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 TxQF3D9hFyUp for ; Mon, 16 Oct 2017 14:31:49 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7B94E132D45 for ; Mon, 16 Oct 2017 14:31:49 -0700 (PDT) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 81AE93A0A3 for ; Mon, 16 Oct 2017 17:31:48 -0400 (EDT) Received: by mail-lf0-f54.google.com with SMTP id a69so18562204lfe.5 for ; Mon, 16 Oct 2017 14:31:48 -0700 (PDT) X-Gm-Message-State: AMCzsaVMxkJYqY9RHGQzmj+08u6useD5wkQucmDCEQf9JkqRlZRSNsb4 MrHLyipDNTWd0EL9VcltLsxGSbx4ZBiZw91HUlg= X-Google-Smtp-Source: ABhQp+QkCoVVgTX3mp1kwisAFrWKDrIEpeWtLAMfD5nRXKLR40ppO9l4kvJGCUH38FizJlmLx4ApBLFXx42avZxWlGw= X-Received: by 10.25.234.66 with SMTP id i63mr3701217lfh.188.1508189507213; Mon, 16 Oct 2017 14:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Mon, 16 Oct 2017 14:31:45 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> From: Patrick McManus Date: Mon, 16 Oct 2017 17:31:45 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mike Bishop Cc: Patrick McManus , Andy Green , Martin Thomson , hybi , Cory Benfield , Patrick McManus , HTTP Working Group Content-Type: multipart/alternative; boundary="94eb2c0ebae0d4e1eb055bb0bbe9" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 21:31:52 -0000 --94eb2c0ebae0d4e1eb055bb0bbe9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop wrote: > Generalizing CONNECT to allow you to tunnel protocols other than TCP =E2= =80=93 or > rather, to explicitly state what protocol the other side should be > expecting the TCP connection to speak =E2=80=93 is a neat approach. So f= irst off, > kudos! > > > > If you say you=E2=80=99re upgrading to WebSockets, then I=E2=80=99d expec= t it to actually > upgrade straight to WebSockets, not an HTTP/1.1 request which is expected > to then upgrade to WebSockets. I understand that would entail putting al= l > the WebSocket negotiation headers on the CONNECT itself, etc. and I=E2=80= =99m > sympathetic to the argument that it is a larger change that may produce a > roadbump. But you=E2=80=99re making a commitment at the HTTP/2 layer tha= t actually > means nothing (=E2=80=9Cwss=E2=80=9D scheme, =E2=80=9Cwebsocket=E2=80=9D = :protocol). > > I hear what you're saying.. but I think you're going a touch too far. websocket means 6455 which has all that h1 stuff as part of its configuration.. I think it would be totally fair to say such a server could have a more constrained parser that failed any non-ws compliant handshake even if it were valid h1. Mostly I think it becomes an insanely ugly what to do websocket parameter exchange. I think of origin info (scheme and authority) more as keys to route the CONNECT request.. it's :protocol that defines what to do in the tunnel. I admit I did consider calling it :alpn (which has a similar kind of property.. its a route of sorts but it doesn't bear the SETTINGS or magic of h2) You have kind of let the cat out of the bag at just doing an h1 connect. That's actually possible with the draft (or at least envisioned) as I defined :protocol separate from the websocket specific stuff... but I kinda hope to never speak of it again :) This is a tough one - its definitely going for simplicity as its main goal.. that means ignoring many places that can be improved. That's a choice based on a] the history of other efforts seem to suggest there is no stomach for complexity/risk here b] we hear about this problem enough that I think its worth seeing if this can be m ade a consensus mvp c] my belief that websockets is a transitional technology - it will be around for years but some kind of native http will supplant it. ymmv (more than usual on this one!) -P > > > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance insi= de the > tunneled connection, why don=E2=80=99t you just say that you=E2=80=99re C= ONNECTing to an > HTTP/1.1 tunnel? That=E2=80=99s then treated as HTTP/1.1 over TCP, which= is fully > allowed to do Upgrade itself. If you=E2=80=99re sure that=E2=80=99s the = path you want, > then simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 in= side the > stream. Incidentally, that might be a nice alternative for dealing with > HTTP_1_1_REQUIRED responses, too! > > > > *From:* Patrick McManus [mailto:pmcmanus@mozilla.com] > *Sent:* Monday, October 16, 2017 5:16 AM > *To:* Andy Green > *Cc:* Martin Thomson ; Patrick McManus < > pmcmanus@mozilla.com>; hybi ; Cory Benfield < > cory@lukasa.co.uk>; Patrick McManus ; HTTP Working > Group > *Subject:* Re: [hybi] New Version Notification for > draft-mcmanus-httpbis-h2-websockets-00.txt > > > > > > > > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green wrote: > > > You can probably pipeline the CONNECT + ws handshake though, Patrick show= s > them sequentially and I didn't think about it myself. > > > > right. The example is just for clarity and cannot show all expressions of > h2 flows. > > > > CONNECT + DATA before the response headers is pretty much the h2 analog o= f > TCP Fast Open. The devil is in the details.. That's a general CONNECT + > DATA issue not limited to the protocol upgrade described here so I don't > think its worth discussion in a websockets rfc. > > > > I think the path to success here hinges on a very tight scoping of work > and therefore optimizing handshake latency is a non-goal of this effort. > > > > > > Still only two round trips. > > > - SETTINGS - SETTINGS > - GET /index.html > - 200 HEADERS + DATA > > - :method CONNECT > - DATA ws handshake > - 200 HEADERS > - DATA ws handshake final > - DATA... > > - DATA ... - DATA... > > With the part of the pipelining that is legal for ws, two round trips > before the client can start to send data and 1.5 before the server can se= nd > data... if it's true then you're right it's not so bad. > > Were you concerned that the client needs to learn that the server > supports websockets and not just :protocol? > > > No I just followed Patrick's sequencing; he shows them serialized. But > you're right at least the CONNECT + ws handshake can probably be pipeline= d. > > That's also going to be a variation from normal h2 HEADERS flow if I > understood it, on one stream there will be END_HEADERs coming twice (for > the CONNECT and the ws handshake separately) > > Anyway you are right, it makes any difference with PUSH_PROMISE probably > not worth the effort. > > -Andy > > > --94eb2c0ebae0d4e1eb055bb0bbe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

Generalizing CONNECT to allow you to tunnel protocol= s other than TCP =E2=80=93 or rather, to explicitly state what protocol the= other side should be expecting the TCP connection to speak =E2=80=93 is a = neat approach.=C2=A0 So first off, kudos!

=C2=A0

If you say you=E2=80=99re upgrading to WebSockets, t= hen I=E2=80=99d expect it to actually upgrade straight to WebSockets, not a= n HTTP/1.1 request which is expected to then upgrade to WebSockets.=C2=A0 I= understand that would entail putting all the WebSocket negotiation headers on the CONNECT itself, etc. and I=E2=80=99m sympatheti= c to the argument that it is a larger change that may produce a roadbump.= =C2=A0 But you=E2=80=99re making a commitment at the HTTP/2 layer that actu= ally means nothing (=E2=80=9Cwss=E2=80=9D scheme, =E2=80=9Cwebsocket=E2=80= =9D :protocol).


<= div>I hear what you're saying.. but I think you're going a touch to= o far. websocket means 6455 which has all that h1 stuff as part of its conf= iguration.. I think it would be totally fair to say such a server could hav= e a more constrained parser that failed any non-ws compliant handshake even= if it were valid h1. Mostly I think it becomes an insanely ugly what to do= websocket parameter exchange.

I think of orig= in info (scheme and authority) more as keys to route the CONNECT request.. = it's :protocol that defines what to do in the tunnel. I admit I did con= sider calling it :alpn (which has a similar kind of property.. its a route = of sorts but it doesn't bear the SETTINGS or magic of h2)

You have kind of let the cat out of the bag at just doing a= n h1 connect. That's actually possible with the draft (or at least envi= sioned) as I defined :protocol separate from the websocket specific stuff..= . but I kinda hope to never speak of it again :)

This is a tough one - its definitely going for simplicity as its main go= al.. that means ignoring many places that can be improved. That's a cho= ice based on
=C2=A0a] the history of other efforts seem to sugges= t there is no stomach for complexity/risk here
=C2=A0b] we hear a= bout this problem enough that I think its worth seeing if this can be m ade= a consensus mvp
=C2=A0c] my belief that websockets is a transiti= onal technology - it will be around for years but some kind of native http = will supplant it.

ymmv (more than usual on thi= s one!)

-P

=C2=A0

=C2=A0

Given that you=E2=80=99re doing the full Upgrade-to-= WebSockets dance inside the tunneled connection, why don=E2=80=99t you just= say that you=E2=80=99re CONNECTing to an HTTP/1.1 tunnel?=C2=A0 That=E2=80= =99s then treated as HTTP/1.1 over TCP, which is fully allowed to do Upgrad= e itself.=C2=A0 If you=E2=80=99re sure that=E2=80=99s the path you want, the= n simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 inside = the stream.=C2=A0 Incidentally, that might be a nice alternative for dealin= g with HTTP_1_1_REQUIRED responses, too!

=C2=A0

From: Patrick McManus [mailto:pmcmanus@mozilla.com]
Sent: Monday, October 16, 2017 5:16 AM
To: Andy Green <andy@warmcat.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; Patrick McManus <pmcmanus@mozilla.com<= /a>>; hybi <hybi@i= etf.org>; Cory Benfield <cory@lukasa.co.uk>; Patrick McManus <mcmanus@ducksong.com>; = HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpb= is-h2-websockets-00.txt

=C2=A0

=C2=A0

=C2=A0

On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <andy@warmcat.com>= wrote:


You can probably pipeline the CONNECT + ws handshake though, Patrick shows = them sequentially and I didn't think about it myself.

=C2=A0

right. The example is just for clarity and cannot sh= ow all expressions of h2 flows.

=C2=A0

CONNECT + DATA before the response headers is pretty= much the h2 analog of TCP Fast Open. The devil is in the details.. That= 9;s a general CONNECT + DATA issue not limited to the protocol upgrade desc= ribed here so I don't think its worth discussion in a websockets rfc.

=C2=A0

I think the path to success here hinges on a very ti= ght scoping of work and therefore optimizing handshake latency is a non-goa= l of this effort.

=C2=A0

=C2=A0

Still only two round trips.


=C2=A0- SETTINGS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 - SETTINGS
=C2=A0- GET /index.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 200 HEADERS= + DATA

=C2=A0- :method CONNECT
=C2=A0- DATA ws handshake
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 200 HEADER= S
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DATA ws ha= ndshake final
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DATA...
=C2=A0- DATA ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DATA...
With the part of the pipelining that is legal for ws, two round trips befor= e the client can start to send data and 1.5 before the server can send data= ... if it's true then you're right it's not so bad.

Were you concerned that the client needs to learn th= at the server
supports websockets and not just :protocol?


No I just followed Patrick's sequencing; he shows them serialized.=C2= =A0 But you're right at least the CONNECT + ws handshake can probably b= e pipelined.

That's also going to be a variation from normal h2 HEADERS flow if I un= derstood it, on one stream there will be END_HEADERs coming twice (for the = CONNECT and the ws handshake separately)

Anyway you are right, it makes any difference with PUSH_PROMISE probably no= t worth the effort.

-Andy

=C2=A0


--94eb2c0ebae0d4e1eb055bb0bbe9-- From nobody Tue Oct 17 01:59:13 2017 Return-Path: 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 0CB5E1320D9 for ; Tue, 17 Oct 2017 01:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=cld4VgDj; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=MiUT/LZ4 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 aFpHGsFN8H63 for ; Tue, 17 Oct 2017 01:59:08 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CABC1332D5 for ; Tue, 17 Oct 2017 01:59:07 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id E4F9F15A0F37; Tue, 17 Oct 2017 10:59:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508230745; bh=IBoiWGPBP6zK8wPy+02UCfezao2se0tCb5he+sZ6w6w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cld4VgDjqTuRZaElQzC9rReZ5d8heAYR4nrntjTfdwxYGXOCSpyYz2ueAYxBnh50g XaeUXjSrGCAYKegjqFFHQwQ+DsiLthHBMLv0rr+Xu6R63HT+MQcIzJRebKzBsuR2D0 UgbzY1fHgIZ+uLAUfD54bDZStsJZsm4SyR1pC5PU= Received: from resistance.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 223BE15A0A6F; Tue, 17 Oct 2017 10:59:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508230740; bh=IBoiWGPBP6zK8wPy+02UCfezao2se0tCb5he+sZ6w6w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MiUT/LZ4aLPFONXDm4Y9FymMS8slHWjmQ+OQugBfe+OzBpa37eNtqCnFog8YFb3hF g/+illBv+pylzFf6dpOSA4RWq5S9op0H34auR1WaNTRVrrqdzig3/Au2YYjBJSLfx3 ZB5fzehQCEn5m5fZavOO35xOhuWh1RK+yIbhmZdE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Stefan Eissing In-Reply-To: Date: Tue, 17 Oct 2017 10:58:59 +0200 Cc: Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> To: Patrick McManus X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 08:59:11 -0000 > Am 16.10.2017 um 23:31 schrieb Patrick McManus : >=20 > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop = wrote: [...] >=20 > I hear what you're saying.. but I think you're going a touch too far. = websocket means 6455 which has all that h1 stuff as part of its = configuration.. I think it would be totally fair to say such a server = could have a more constrained parser that failed any non-ws compliant = handshake even if it were valid h1. Mostly I think it becomes an = insanely ugly what to do websocket parameter exchange. >=20 > I think of origin info (scheme and authority) more as keys to route = the CONNECT request.. it's :protocol that defines what to do in the = tunnel. I admit I did consider calling it :alpn (which has a similar = kind of property.. its a route of sorts but it doesn't bear the SETTINGS = or magic of h2) Me stupid. Me asking, why not :upgrade? ht;dr (have time, do read) As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this = stream from now on, afaict. =46rom a server implementation pov that opens a larger can of worms. It = would mean warming up the HTTP/1.1 engine for the DATA on this stream. = That needs some extra care so that it does only safe things inside a h2 = stream. On first glance, it seems to be easier and safer to do the = stream :upgrade inside the h2 protocol handling itself. Just my initial gut reaction... -Stefan > You have kind of let the cat out of the bag at just doing an h1 = connect. That's actually possible with the draft (or at least = envisioned) as I defined :protocol separate from the websocket specific = stuff... but I kinda hope to never speak of it again :) >=20 > This is a tough one - its definitely going for simplicity as its main = goal.. that means ignoring many places that can be improved. That's a = choice based on > a] the history of other efforts seem to suggest there is no stomach = for complexity/risk here > b] we hear about this problem enough that I think its worth seeing if = this can be m ade a consensus mvp > c] my belief that websockets is a transitional technology - it will = be around for years but some kind of native http will supplant it. >=20 > ymmv (more than usual on this one!) >=20 > -P >=20 > =20 > =20 >=20 > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance = inside the tunneled connection, why don=E2=80=99t you just say that = you=E2=80=99re CONNECTing to an HTTP/1.1 tunnel? That=E2=80=99s then = treated as HTTP/1.1 over TCP, which is fully allowed to do Upgrade = itself. If you=E2=80=99re sure that=E2=80=99s the path you want, then = simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 inside = the stream. Incidentally, that might be a nice alternative for dealing = with HTTP_1_1_REQUIRED responses, too! >=20 > =20 >=20 > From: Patrick McManus [mailto:pmcmanus@mozilla.com]=20 > Sent: Monday, October 16, 2017 5:16 AM > To: Andy Green > Cc: Martin Thomson ; Patrick McManus = ; hybi ; Cory Benfield = ; Patrick McManus ; HTTP = Working Group > Subject: Re: [hybi] New Version Notification for = draft-mcmanus-httpbis-h2-websockets-00.txt >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green wrote: >=20 >=20 > You can probably pipeline the CONNECT + ws handshake though, Patrick = shows them sequentially and I didn't think about it myself. >=20 > =20 >=20 > right. The example is just for clarity and cannot show all expressions = of h2 flows. >=20 > =20 >=20 > CONNECT + DATA before the response headers is pretty much the h2 = analog of TCP Fast Open. The devil is in the details.. That's a general = CONNECT + DATA issue not limited to the protocol upgrade described here = so I don't think its worth discussion in a websockets rfc. >=20 > =20 >=20 > I think the path to success here hinges on a very tight scoping of = work and therefore optimizing handshake latency is a non-goal of this = effort. >=20 > =20 >=20 > =20 >=20 > Still only two round trips. >=20 >=20 > - SETTINGS - SETTINGS > - GET /index.html > - 200 HEADERS + DATA >=20 > - :method CONNECT > - DATA ws handshake > - 200 HEADERS > - DATA ws handshake final > - DATA... >=20 > - DATA ... - DATA... >=20 > With the part of the pipelining that is legal for ws, two round trips = before the client can start to send data and 1.5 before the server can = send data... if it's true then you're right it's not so bad. >=20 > Were you concerned that the client needs to learn that the server > supports websockets and not just :protocol? >=20 >=20 > No I just followed Patrick's sequencing; he shows them serialized. = But you're right at least the CONNECT + ws handshake can probably be = pipelined. >=20 > That's also going to be a variation from normal h2 HEADERS flow if I = understood it, on one stream there will be END_HEADERs coming twice (for = the CONNECT and the ws handshake separately) >=20 > Anyway you are right, it makes any difference with PUSH_PROMISE = probably not worth the effort. >=20 > -Andy >=20 > =20 >=20 >=20 From nobody Tue Oct 17 07:34:30 2017 Return-Path: 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 706F7132D49 for ; Tue, 17 Oct 2017 07:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 r5SKazCwrT24 for ; Tue, 17 Oct 2017 07:34:21 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 26E68132D51 for ; Tue, 17 Oct 2017 07:34:21 -0700 (PDT) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 009633A0A9 for ; Tue, 17 Oct 2017 10:34:18 -0400 (EDT) Received: by mail-lf0-f54.google.com with SMTP id b190so2253149lfg.9 for ; Tue, 17 Oct 2017 07:34:18 -0700 (PDT) X-Gm-Message-State: AMCzsaW7QF8+YGHK9HY7EsR6Umw5NE0hpCCz4zSSjrNCGUbyrBIAnG6v B7U25A8xS4BIcZecQw7ruEU588mwScHGxBbbtGU= X-Google-Smtp-Source: ABhQp+SEg6rQghuwGfPEsZelzeaCeCD2OHJdGBmuxzG0N9iZZUbDP5oE8O+vdmdY2pycHCCZmbBAW+X5iaqoeglIyIw= X-Received: by 10.25.234.66 with SMTP id i63mr4608092lfh.188.1508250857615; Tue, 17 Oct 2017 07:34:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Tue, 17 Oct 2017 07:34:16 -0700 (PDT) In-Reply-To: <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> From: Patrick McManus Date: Tue, 17 Oct 2017 10:34:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Stefan Eissing Cc: Patrick McManus , Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Type: multipart/alternative; boundary="94eb2c0ebae099b7b4055bbf0417" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:34:28 -0000 --94eb2c0ebae099b7b4055bbf0417 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Clearly substituting the h1 exchange out in favor of a new websockets specific exchange that contained sub-protocol and version tokens would look better on paper... I actually thought diverging from 6455 would make people LESS likely to implement. Maybe I'm wrong. So let's poll - please speak up if you have a ws impl (either client or server): If the spec added a new websockets specific parameter negotiation and removed the H1 syntax it would make me a] MORE likely to implement b] LESS likely to implement c] wouldn't change my behavior but I like it more d] wouldn't change my behavior but it would be more painful (or like it less) e] really don't care at all. On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing < stefan.eissing@greenbytes.de> wrote: > > > > Am 16.10.2017 um 23:31 schrieb Patrick McManus : > > > > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > [...] > > > > I hear what you're saying.. but I think you're going a touch too far. > websocket means 6455 which has all that h1 stuff as part of its > configuration.. I think it would be totally fair to say such a server cou= ld > have a more constrained parser that failed any non-ws compliant handshake > even if it were valid h1. Mostly I think it becomes an insanely ugly what > to do websocket parameter exchange. > > > > I think of origin info (scheme and authority) more as keys to route the > CONNECT request.. it's :protocol that defines what to do in the tunnel. I > admit I did consider calling it :alpn (which has a similar kind of > property.. its a route of sorts but it doesn't bear the SETTINGS or magic > of h2) > > Me stupid. Me asking, why not :upgrade? > > ht;dr (have time, do read) > > As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this strea= m > from now on, afaict. > > From a server implementation pov that opens a larger can of worms. It > would mean warming up the HTTP/1.1 engine for the DATA on this stream. Th= at > needs some extra care so that it does only safe things inside a h2 stream= . > On first glance, it seems to be easier and safer to do the stream :upgrad= e > inside the h2 protocol handling itself. > > Just my initial gut reaction... > > -Stefan > > > You have kind of let the cat out of the bag at just doing an h1 connect= . > That's actually possible with the draft (or at least envisioned) as I > defined :protocol separate from the websocket specific stuff... but I kin= da > hope to never speak of it again :) > > > > This is a tough one - its definitely going for simplicity as its main > goal.. that means ignoring many places that can be improved. That's a > choice based on > > a] the history of other efforts seem to suggest there is no stomach fo= r > complexity/risk here > > b] we hear about this problem enough that I think its worth seeing if > this can be m ade a consensus mvp > > c] my belief that websockets is a transitional technology - it will be > around for years but some kind of native http will supplant it. > > > > ymmv (more than usual on this one!) > > > > -P > > > > > > > > > > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance in= side the > tunneled connection, why don=E2=80=99t you just say that you=E2=80=99re C= ONNECTing to an > HTTP/1.1 tunnel? That=E2=80=99s then treated as HTTP/1.1 over TCP, which= is fully > allowed to do Upgrade itself. If you=E2=80=99re sure that=E2=80=99s the = path you want, > then simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 in= side the > stream. Incidentally, that might be a nice alternative for dealing with > HTTP_1_1_REQUIRED responses, too! > > > > > > > > From: Patrick McManus [mailto:pmcmanus@mozilla.com] > > Sent: Monday, October 16, 2017 5:16 AM > > To: Andy Green > > Cc: Martin Thomson ; Patrick McManus < > pmcmanus@mozilla.com>; hybi ; Cory Benfield < > cory@lukasa.co.uk>; Patrick McManus ; HTTP Working > Group > > Subject: Re: [hybi] New Version Notification for > draft-mcmanus-httpbis-h2-websockets-00.txt > > > > > > > > > > > > > > > > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green wrote: > > > > > > You can probably pipeline the CONNECT + ws handshake though, Patrick > shows them sequentially and I didn't think about it myself. > > > > > > > > right. The example is just for clarity and cannot show all expressions > of h2 flows. > > > > > > > > CONNECT + DATA before the response headers is pretty much the h2 analog > of TCP Fast Open. The devil is in the details.. That's a general CONNECT = + > DATA issue not limited to the protocol upgrade described here so I don't > think its worth discussion in a websockets rfc. > > > > > > > > I think the path to success here hinges on a very tight scoping of work > and therefore optimizing handshake latency is a non-goal of this effort. > > > > > > > > > > > > Still only two round trips. > > > > > > - SETTINGS - SETTINGS > > - GET /index.html > > - 200 HEADERS + DATA > > > > - :method CONNECT > > - DATA ws handshake > > - 200 HEADERS > > - DATA ws handshake final > > - DATA... > > > > - DATA ... - DATA... > > > > With the part of the pipelining that is legal for ws, two round trips > before the client can start to send data and 1.5 before the server can se= nd > data... if it's true then you're right it's not so bad. > > > > Were you concerned that the client needs to learn that the server > > supports websockets and not just :protocol? > > > > > > No I just followed Patrick's sequencing; he shows them serialized. But > you're right at least the CONNECT + ws handshake can probably be pipeline= d. > > > > That's also going to be a variation from normal h2 HEADERS flow if I > understood it, on one stream there will be END_HEADERs coming twice (for > the CONNECT and the ws handshake separately) > > > > Anyway you are right, it makes any difference with PUSH_PROMISE probabl= y > not worth the effort. > > > > -Andy > > > > > > > > > > --94eb2c0ebae099b7b4055bbf0417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Clearly substituting the h1 exchange out in favor of = a new websockets specific exchange that contained sub-protocol and version = tokens would look better on paper... I actually thought diverging from 6455= would make people LESS likely to implement. Maybe I'm wrong.

So let's poll - please speak up if you have a ws impl (= either client or server):

If the spec added a new = websockets specific parameter negotiation and removed the H1 syntax it woul= d make me
=C2=A0a] MORE likely to implement
=C2=A0b] LE= SS likely to implement
=C2=A0c] wouldn't change my behavior b= ut I like it more
=C2=A0d] wouldn't change my behavior but it= would be more painful (or like it less)
=C2=A0e] really don'= t care at all.

On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <s= tefan.eissing@greenbytes.de> wrote:


> Am 16.10.2017 um 23:31 schrieb Patrick McManus <pmcmanus@mozilla.com>:
>
> On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
[...]
>
> I hear what you're saying.. but I think you're going a touch t= oo far. websocket means 6455 which has all that h1 stuff as part of its con= figuration.. I think it would be totally fair to say such a server could ha= ve a more constrained parser that failed any non-ws compliant handshake eve= n if it were valid h1. Mostly I think it becomes an insanely ugly what to d= o websocket parameter exchange.
>
> I think of origin info (scheme and authority) more as keys to route th= e CONNECT request.. it's :protocol that defines what to do in the tunne= l. I admit I did consider calling it :alpn (which has a similar kind of pro= perty.. its a route of sorts but it doesn't bear the SETTINGS or magic = of h2)

Me stupid. Me asking, why not :upgrade?

ht;dr (have time, do read)

As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this str= eam from now on, afaict.

>From a server implementation pov that opens a larger can of worms. It would= mean warming up the HTTP/1.1 engine for the DATA on this stream. That need= s some extra care so that it does only safe things inside a h2 stream. On f= irst glance, it seems to be easier and safer to do the stream :upgrade insi= de the h2 protocol handling itself.

Just my initial gut reaction...

-Stefan

> You have kind of let the cat out of the bag at just doing an h1 connec= t. That's actually possible with the draft (or at least envisioned) as = I defined :protocol separate from the websocket specific stuff... but I kin= da hope to never speak of it again :)
>
> This is a tough one - its definitely going for simplicity as its main = goal.. that means ignoring many places that can be improved. That's a c= hoice based on
>=C2=A0 a] the history of other efforts seem to suggest there is no stom= ach for complexity/risk here
>=C2=A0 b] we hear about this problem enough that I think its worth seei= ng if this can be m ade a consensus mvp
>=C2=A0 c] my belief that websockets is a transitional technology - it w= ill be around for years but some kind of native http will supplant it.
>
> ymmv (more than usual on this one!)
>
> -P
>
>
>
>
> Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance i= nside the tunneled connection, why don=E2=80=99t you just say that you=E2= =80=99re CONNECTing to an HTTP/1.1 tunnel?=C2=A0 That=E2=80=99s then treate= d as HTTP/1.1 over TCP, which is fully allowed to do Upgrade itself.=C2=A0 = If you=E2=80=99re sure that=E2=80=99s the path you want, then simply say in= the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 inside the stream.=C2= =A0 Incidentally, that might be a nice alternative for dealing with HTTP_1_= 1_REQUIRED responses, too!
>
>
>
> From: Patrick McManus [mailto:= pmcmanus@mozilla.com]
> Sent: Monday, October 16, 2017 5:16 AM
> To: Andy Green <andy@warmcat.co= m>
> Cc: Martin Thomson <mar= tin.thomson@gmail.com>; Patrick McManus <pmcmanus@mozilla.com>; hybi <hybi@ietf.org>; Cory Benfield <cory@lukasa.co.uk>; Patrick McManus <mcmanus@ducksong.com>; HTTP Working Grou= p <ietf-http-wg@w3.org> > Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis= -h2-websockets-00.txt
>
>
>
>
>
>
>
> On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <andy@warmcat.com> wrote:
>
>
> You can probably pipeline the CONNECT + ws handshake though, Patrick s= hows them sequentially and I didn't think about it myself.
>
>
>
> right. The example is just for clarity and cannot show all expressions= of h2 flows.
>
>
>
> CONNECT + DATA before the response headers is pretty much the h2 analo= g of TCP Fast Open. The devil is in the details.. That's a general CONN= ECT + DATA issue not limited to the protocol upgrade described here so I do= n't think its worth discussion in a websockets rfc.
>
>
>
> I think the path to success here hinges on a very tight scoping of wor= k and therefore optimizing handshake latency is a non-goal of this effort.<= br> >
>
>
>
>
> Still only two round trips.
>
>
>=C2=A0 - SETTINGS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 - SETTINGS
>=C2=A0 - GET /index.html
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 200 HE= ADERS + DATA
>
>=C2=A0 - :method CONNECT
>=C2=A0 - DATA ws handshake
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = 200 HEADERS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = DATA ws handshake final
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = DATA...
>
>=C2=A0 - DATA ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DATA= ...
>
> With the part of the pipelining that is legal for ws, two round trips = before the client can start to send data and 1.5 before the server can send= data... if it's true then you're right it's not so bad.
>
> Were you concerned that the client needs to learn that the server
> supports websockets and not just :protocol?
>
>
> No I just followed Patrick's sequencing; he shows them serialized.= =C2=A0 But you're right at least the CONNECT + ws handshake can probabl= y be pipelined.
>
> That's also going to be a variation from normal h2 HEADERS flow if= I understood it, on one stream there will be END_HEADERs coming twice (for= the CONNECT and the ws handshake separately)
>
> Anyway you are right, it makes any difference with PUSH_PROMISE probab= ly not worth the effort.
>
> -Andy
>
>
>
>


--94eb2c0ebae099b7b4055bbf0417-- From nobody Tue Oct 17 07:38:24 2017 Return-Path: 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 390D7134226 for ; Tue, 17 Oct 2017 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 kCQe-RmuEj7w for ; Tue, 17 Oct 2017 07:38:21 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 07CEF132F6C for ; Tue, 17 Oct 2017 07:38:10 -0700 (PDT) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6BC3C3A0AA for ; Tue, 17 Oct 2017 10:38:09 -0400 (EDT) Received: by mail-lf0-f54.google.com with SMTP id a16so2282232lfk.0 for ; Tue, 17 Oct 2017 07:38:09 -0700 (PDT) X-Gm-Message-State: AMCzsaWw+AW9fbH4PMlLyB2OsLDjxsmqkxRJW8XfekJPQb1QZxcx9cjY DnWsJgMm8BzyvAe0i4bKRwePi8sGS1tBOOzfBCw= X-Google-Smtp-Source: ABhQp+RlF8mYwQViGZ9ALNRLOPn1ljJKg9g8eIMNrZ58CQ74FtsEwJsfGHW2CuRGq+rPGMCIjBUpEP8pJgZAsVgmPFE= X-Received: by 10.46.56.20 with SMTP id f20mr1012730lja.189.1508251088216; Tue, 17 Oct 2017 07:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Tue, 17 Oct 2017 07:38:06 -0700 (PDT) In-Reply-To: <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> From: Patrick McManus Date: Tue, 17 Oct 2017 10:38:06 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Stefan Eissing Cc: Patrick McManus , Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Type: multipart/alternative; boundary="089e0823e0b45867fe055bbf129f" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:38:22 -0000 --089e0823e0b45867fe055bbf129f Content-Type: text/plain; charset="UTF-8" On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing < stefan.eissing@greenbytes.de> wrote: > > Me stupid. Me asking, why not :upgrade? > > because its not upgrading anything to a higher version. I'm sure 6455 would have used a different name except they were reusing existing h1 infrastructure. --089e0823e0b45867fe055bbf129f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <stefan.eissing@g= reenbytes.de> wrote:
=
Me stupid. Me asking, why not :upgrade?


because its not upgrading anything to = a higher version. I'm sure 6455 would have used a different name except= they were reusing existing h1 infrastructure.
=C2=A0

--089e0823e0b45867fe055bbf129f-- From nobody Tue Oct 17 07:41:31 2017 Return-Path: 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 83921134216 for ; Tue, 17 Oct 2017 07:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=hfxl/3px; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=hfxl/3px 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 AOoZeq60SeHT for ; Tue, 17 Oct 2017 07:41:28 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CD4134285 for ; Tue, 17 Oct 2017 07:40:35 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id A432015A04D3; Tue, 17 Oct 2017 16:40:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508251233; bh=985fdbgb08VMq11pNDUjE/hFPHFu54b5ZGcCjUI236g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=hfxl/3pxnpChovNaAoRX47SXCml757ET2g6sFGlcmfMJ1GPMLS1ais0O3nzT9T2Lh 5z4QoLXTnEKytp8UO/b2zb4aNtRWq1AOiJ+PNGkg7sgQvu77zoseRPozISxBQ4g2Ac EeV0OEn68ecq5ISsf1HMx5GE3cz+NOqUO51ZDjpg= Received: from resistance.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id C64E515A021E; Tue, 17 Oct 2017 16:40:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508251233; bh=985fdbgb08VMq11pNDUjE/hFPHFu54b5ZGcCjUI236g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=hfxl/3pxnpChovNaAoRX47SXCml757ET2g6sFGlcmfMJ1GPMLS1ais0O3nzT9T2Lh 5z4QoLXTnEKytp8UO/b2zb4aNtRWq1AOiJ+PNGkg7sgQvu77zoseRPozISxBQ4g2Ac EeV0OEn68ecq5ISsf1HMx5GE3cz+NOqUO51ZDjpg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Stefan Eissing In-Reply-To: Date: Tue, 17 Oct 2017 16:40:32 +0200 Cc: Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <7ADE2BB9-BDE8-4FDC-BFA2-59D066D65067@greenbytes.de> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> To: Patrick McManus X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:41:29 -0000 > Am 17.10.2017 um 16:38 schrieb Patrick McManus : >=20 > On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing = wrote: >=20 > Me stupid. Me asking, why not :upgrade? >=20 >=20 > because its not upgrading anything to a higher version. I'm sure 6455 = would have used a different name except they were reusing existing h1 = infrastructure. rfc7230, ch. 6.7 "The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection." Nothing about version here. I do not mind another header name, but if it = does the same thing... Cheers, Stefan From nobody Tue Oct 17 07:45:59 2017 Return-Path: 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 215FC13421D for ; Tue, 17 Oct 2017 07:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no 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 et1PXNbEZBGq for ; Tue, 17 Oct 2017 07:45:53 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 0057E134218 for ; Tue, 17 Oct 2017 07:45:52 -0700 (PDT) Received: from [192.168.1.102] ([85.60.142.46]) by mrelayeu.kundenserver.de (mreue101 [212.227.15.183]) with ESMTPSA (Nemesis) id 0LjrTN-1dXtGG1C1Z-00bsAW; Tue, 17 Oct 2017 16:45:49 +0200 To: Patrick McManus Cc: hybi , HTTP Working Group References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= Organization: Nine Nines Message-ID: Date: Tue, 17 Oct 2017 15:45:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Ccbk0ddPFrqAnwmOeFa1UMunE4TQ/C2BNoPGQOe64aTEaPJX3sl cLNnUa+EwJxNTzD+vx+21TL13YJQh0wRkzRoseCRwqF5I92SZB1KZbVFZfNoolQLsq/B8O+ 4yhNt3qZGhxR+HAi38yp3Xik9d/pdBg8P3L7jUtUjRDv1sDKQ7q+rScr0h/72AXrIDatnz9 2gWKQnu624z0zs2vs5OYw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ziSbF9cB//A=:EK3ZyHYMRE1/34kmwRL2p+ V1o/ZRlewjZwFrbDCgOEgR766bZh8kAWvXtKP6VJG1R8OHUuVvR7QEYQP1TxYEQR8yY5sZ1hj 4FTvmL/XTYYBXCtnLies7Vm8zvUqWZmAOrRXi1cXSQHf6j6Oy3rOt0FKcBiE3JNx/aLDcgeeG Ytlf3g9Mdlx4UR5HUznR+hc1nW8JAPGi2GEfugKxnJTLSh2jRsnV4fFIQJi/kSrvqe9Jwh97n 7/6y1G/CVoDF+xUrgJ2kpUhA3FBCIh7zMFSqBXKYUqAYZqlCzk8vEOaDNDjQZMpH3XFiYaPON okoJVvB7cVrBMQALxpRLcWJCqVRNR35NK1HGicDvNvhgU6O3iVwNWql5emYetDai84rNrfJXh J4Kv4wYmELBMfs2mKwr7/SFjfPT5LikYo7gC0c/95o6iLO6WICROKh72tGqrTBV+FugQSpv4I TLbGHDtPmLSU2au8RZ+t9BSAg37hnutcV1tk5AP/7dX/OF96GDDX/oEskZaSZqVXNtKcnfCV3 mxUQomaCTjlLrjUa5uwGx5Nts67qrLJryXHpLrPn5zQJAmHK5I+V75tHRFkCckP0p6gvUzOzD RIvvQYO296GyZ1GZ2nYq3RdJHaOu8alKZHzvV8VkyYeFebEwRP17sbxJMiaMhWKcddtX8QZDZ 2/dJ/U8JWVoalCZ8FHs6ITwsh5JVBvNPPN3pOiVwrn2JdPg+Z9AuXwxtTs4GPSgRmPxMau6D6 QljQGd1H8tsSC1e8GlVNU5ILXPWH+ZjbAzEaiLcHg4oAWcUvmWn0x3e9MBA= Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:45:57 -0000 I maintain both a client and server that support Websocket. My opinion: c] wouldn't change my behavior but I like it more I would implement either way, but I currently do not have an implementation for "HTTP/1.1 over h2 DATA frames" so I would need to write new code regardless. It's probably worth pointing out that new implementers only interested in h2 and Websocket could skip the whole HTTP/1.1 text parsing and all its pitfalls entirely. I would also be very happy to drop the masking on the Websocket frames when using Websocket with h2. On 10/17/2017 03:34 PM, Patrick McManus wrote: > Clearly substituting the h1 exchange out in favor of a new websockets > specific exchange that contained sub-protocol and version tokens would > look better on paper... I actually thought diverging from 6455 would > make people LESS likely to implement. Maybe I'm wrong. > > So let's poll - please speak up if you have a ws impl (either client or > server): > > If the spec added a new websockets specific parameter negotiation and > removed the H1 syntax it would make me >  a] MORE likely to implement >  b] LESS likely to implement >  c] wouldn't change my behavior but I like it more >  d] wouldn't change my behavior but it would be more painful (or like > it less) >  e] really don't care at all. > > On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing > > wrote: > > > > > Am 16.10.2017 um 23:31 schrieb Patrick McManus >: > > > > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop > > wrote: > [...] > > > > I hear what you're saying.. but I think you're going a touch too far. websocket means 6455 which has all that h1 stuff as part of its configuration.. I think it would be totally fair to say such a server could have a more constrained parser that failed any non-ws compliant handshake even if it were valid h1. Mostly I think it becomes an insanely ugly what to do websocket parameter exchange. > > > > I think of origin info (scheme and authority) more as keys to route the CONNECT request.. it's :protocol that defines what to do in the tunnel. I admit I did consider calling it :alpn (which has a similar kind of property.. its a route of sorts but it doesn't bear the SETTINGS or magic of h2) > > Me stupid. Me asking, why not :upgrade? > > ht;dr (have time, do read) > > As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this > stream from now on, afaict. > > >From a server implementation pov that opens a larger can of worms. > It would mean warming up the HTTP/1.1 engine for the DATA on this > stream. That needs some extra care so that it does only safe things > inside a h2 stream. On first glance, it seems to be easier and safer > to do the stream :upgrade inside the h2 protocol handling itself. > > Just my initial gut reaction... > > -Stefan > > > You have kind of let the cat out of the bag at just doing an h1 > connect. That's actually possible with the draft (or at least > envisioned) as I defined :protocol separate from the websocket > specific stuff... but I kinda hope to never speak of it again :) > > > > This is a tough one - its definitely going for simplicity as its > main goal.. that means ignoring many places that can be improved. > That's a choice based on > >  a] the history of other efforts seem to suggest there is no > stomach for complexity/risk here > >  b] we hear about this problem enough that I think its worth > seeing if this can be m ade a consensus mvp > >  c] my belief that websockets is a transitional technology - it > will be around for years but some kind of native http will supplant it. > > > > ymmv (more than usual on this one!) > > > > -P > > > > > > > > > > Given that you’re doing the full Upgrade-to-WebSockets dance > inside the tunneled connection, why don’t you just say that you’re > CONNECTing to an HTTP/1.1 tunnel?  That’s then treated as HTTP/1.1 > over TCP, which is fully allowed to do Upgrade itself.  If you’re > sure that’s the path you want, then simply say in the HTTP/2 layer > that you’re doing HTTP/1.1 inside the stream.  Incidentally, that > might be a nice alternative for dealing with HTTP_1_1_REQUIRED > responses, too! > > > > > > > > From: Patrick McManus [mailto:pmcmanus@mozilla.com > ] > > Sent: Monday, October 16, 2017 5:16 AM > > To: Andy Green > > > Cc: Martin Thomson >; Patrick McManus > >; hybi > >; Cory Benfield > >; Patrick McManus > >; HTTP Working > Group > > > Subject: Re: [hybi] New Version Notification for > draft-mcmanus-httpbis-h2-websockets-00.txt > > > > > > > > > > > > > > > > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green > wrote: > > > > > > You can probably pipeline the CONNECT + ws handshake though, > Patrick shows them sequentially and I didn't think about it myself. > > > > > > > > right. The example is just for clarity and cannot show all > expressions of h2 flows. > > > > > > > > CONNECT + DATA before the response headers is pretty much the h2 > analog of TCP Fast Open. The devil is in the details.. That's a > general CONNECT + DATA issue not limited to the protocol upgrade > described here so I don't think its worth discussion in a websockets > rfc. > > > > > > > > I think the path to success here hinges on a very tight scoping > of work and therefore optimizing handshake latency is a non-goal of > this effort. > > > > > > > > > > > > Still only two round trips. > > > > > >  - SETTINGS                      - SETTINGS > >  - GET /index.html > >                  - 200 HEADERS + DATA > > > >  - :method CONNECT > >  - DATA ws handshake > >                   - 200 HEADERS > >                   - DATA ws handshake final > >                   - DATA... > > > >  - DATA ...             - DATA... > > > > With the part of the pipelining that is legal for ws, two round > trips before the client can start to send data and 1.5 before the > server can send data... if it's true then you're right it's not so bad. > > > > Were you concerned that the client needs to learn that the server > > supports websockets and not just :protocol? > > > > > > No I just followed Patrick's sequencing; he shows them > serialized.  But you're right at least the CONNECT + ws handshake > can probably be pipelined. > > > > That's also going to be a variation from normal h2 HEADERS flow > if I understood it, on one stream there will be END_HEADERs coming > twice (for the CONNECT and the ws handshake separately) > > > > Anyway you are right, it makes any difference with PUSH_PROMISE > probably not worth the effort. > > > > -Andy > > > > > > > > > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > -- Loïc Hoguin https://ninenines.eu From nobody Tue Oct 17 07:48:20 2017 Return-Path: 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 4044813421F for ; Tue, 17 Oct 2017 07:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 ntTISLoHDiUh for ; Tue, 17 Oct 2017 07:48:18 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 38945134218 for ; Tue, 17 Oct 2017 07:48:18 -0700 (PDT) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 9D0D13A0AB for ; Tue, 17 Oct 2017 10:48:17 -0400 (EDT) Received: by mail-lf0-f51.google.com with SMTP id w21so2316350lfc.6 for ; Tue, 17 Oct 2017 07:48:17 -0700 (PDT) X-Gm-Message-State: AMCzsaXx2jZrTnJv8zFZaKPNt4zHD+N0bWmI1ZpoYHlb/QagqSsOWfS4 leAZoIKYNXTtshoV5Q43D17Xwnl/sGzP0Qj1ipI= X-Google-Smtp-Source: ABhQp+Ski30d1j2+isInlHkgth3/zTPIy7faLbonjdViaPpKSbRupWacwPHmS4LB6/Uqga5qyQR8Ud+siszgBUnL9+Y= X-Received: by 10.46.56.20 with SMTP id f20mr1025263lja.189.1508251696264; Tue, 17 Oct 2017 07:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Tue, 17 Oct 2017 07:48:15 -0700 (PDT) In-Reply-To: <7ADE2BB9-BDE8-4FDC-BFA2-59D066D65067@greenbytes.de> References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> <7ADE2BB9-BDE8-4FDC-BFA2-59D066D65067@greenbytes.de> From: Patrick McManus Date: Tue, 17 Oct 2017 10:48:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Stefan Eissing Cc: Patrick McManus , Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Type: multipart/alternative; boundary="089e0823e0b4967917055bbf3608" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:48:19 -0000 --089e0823e0b4967917055bbf3608 Content-Type: text/plain; charset="UTF-8" nothing about versions other than the name Upgrade :) On Tue, Oct 17, 2017 at 10:40 AM, Stefan Eissing < stefan.eissing@greenbytes.de> wrote: > > > > Am 17.10.2017 um 16:38 schrieb Patrick McManus : > > > > On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing < > stefan.eissing@greenbytes.de> wrote: > > > > Me stupid. Me asking, why not :upgrade? > > > > > > because its not upgrading anything to a higher version. I'm sure 6455 > would have used a different name except they were reusing existing h1 > infrastructure. > > rfc7230, ch. 6.7 > > "The "Upgrade" header field is intended to provide a simple mechanism > for transitioning from HTTP/1.1 to some other protocol on the same > connection." > > Nothing about version here. I do not mind another header name, but if it > does the same thing... > > Cheers, > > Stefan > > --089e0823e0b4967917055bbf3608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
nothing about versions other than the name Upgrade :)=


On Tue, Oct 17, 2017 at 10:40 AM, Stefan Eissing <ste= fan.eissing@greenbytes.de> wrote:


> Am 17.10.2017 um 16:38 schrieb Patrick McManus <pmcmanus@mozilla.com>:
>
> On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: >
> Me stupid. Me asking, why not :upgrade?
>
>
> because its not upgrading anything to a higher version. I'm sure 6= 455 would have used a different name except they were reusing existing h1 i= nfrastructure.

rfc7230, ch. 6.7

"The "Upgrade" header field is intended to provide a simple = mechanism
=C2=A0 =C2=A0for transitioning from HTTP/1.1 to some other protocol on the = same
=C2=A0 =C2=A0connection."

Nothing about version here. I do not mind another header name, but if it do= es the same thing...

Cheers,

Stefan


--089e0823e0b4967917055bbf3608-- From nobody Tue Oct 17 07:52:54 2017 Return-Path: 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 EB23F132D96 for ; Tue, 17 Oct 2017 07:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=SGCUPBE7; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=kWDylMzb 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 KJL6FS4keEJu for ; Tue, 17 Oct 2017 07:52:51 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D73132D22 for ; Tue, 17 Oct 2017 07:52:50 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id 4784715A2F6F; Tue, 17 Oct 2017 16:52:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508251969; bh=ikbTT4MWgJpXarsaDHG9I8oT2l6JkpDK9i8lpcXhLAw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=SGCUPBE7reb6Qn2V+p8184b30rYWsQrYUlvCbo1he0wjrLfpWRLvt8cJJpUBRbnKW +cxUIKoCHcoKoFkeXdGqPkhIUsYnv9KmqDOi5H/m+0WX/R6ijJKBv4N8NrUWVfLY3R sC/bO6u7+8wWIJDshSxjRrT/olxUIxFFSYEGnQKY= Received: from resistance.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 7BB5B15A021E; Tue, 17 Oct 2017 16:52:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508251959; bh=ikbTT4MWgJpXarsaDHG9I8oT2l6JkpDK9i8lpcXhLAw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kWDylMzbxerlG0lnu6ehKbjm+vvXaD5b/+CEF35/yvPWYJIOKpxTaCkwUVsIJxAMF eDycrlaKTp0s9qsEycdx/9M5I46f0DPGYtoCoF/DtcL2jFAYOPuVPmz446U+QxpPN3 4Omy9O6ySGWm8+SWHDuDAam41S7J2r9xu3eAkeQU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Stefan Eissing In-Reply-To: Date: Tue, 17 Oct 2017 16:52:39 +0200 Cc: Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> To: Patrick McManus X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:52:53 -0000 Thanks for the poll! > Am 17.10.2017 um 16:34 schrieb Patrick McManus : >=20 > Clearly substituting the h1 exchange out in favor of a new websockets = specific exchange that contained sub-protocol and version tokens would = look better on paper... I actually thought diverging from 6455 would = make people LESS likely to implement. Maybe I'm wrong. >=20 > So let's poll - please speak up if you have a ws impl (either client = or server): >=20 > If the spec added a new websockets specific parameter negotiation and = removed the H1 syntax it would make me > a] MORE likely to implement > b] LESS likely to implement > c] wouldn't change my behavior but I like it more > d] wouldn't change my behavior but it would be more painful (or like = it less) > e] really don't care at all. c) However, it is not really clear to me why we need another parameter = negotiation,=20 besides defining what rfc6455, ch. 4.2.1 means by "Upgrade" and = "Connection" header requirements on a h2 stream. You most likely have more ws experience than myself, so please = understand this as a real question for me and not some rhetoric hand-waving. To explain my pov: the h2 code sits on the connection/stream, will = detect the to-be-defined equivalent of a "Upgrade: websocket" request header and = feed the server-internal, proprietary websocket implementation all the information it desires. = h1/h2 protocol serialization is basically over at this point. That is how I look at it. This might be totally different for other = peoples implementation, of course. > On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing = wrote: >=20 >=20 > > Am 16.10.2017 um 23:31 schrieb Patrick McManus = : > > > > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop = wrote: > [...] > > > > I hear what you're saying.. but I think you're going a touch too = far. websocket means 6455 which has all that h1 stuff as part of its = configuration.. I think it would be totally fair to say such a server = could have a more constrained parser that failed any non-ws compliant = handshake even if it were valid h1. Mostly I think it becomes an = insanely ugly what to do websocket parameter exchange. > > > > I think of origin info (scheme and authority) more as keys to route = the CONNECT request.. it's :protocol that defines what to do in the = tunnel. I admit I did consider calling it :alpn (which has a similar = kind of property.. its a route of sorts but it doesn't bear the SETTINGS = or magic of h2) >=20 > Me stupid. Me asking, why not :upgrade? >=20 > ht;dr (have time, do read) >=20 > As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this = stream from now on, afaict. >=20 > >=46rom a server implementation pov that opens a larger can of worms. = It would mean warming up the HTTP/1.1 engine for the DATA on this = stream. That needs some extra care so that it does only safe things = inside a h2 stream. On first glance, it seems to be easier and safer to = do the stream :upgrade inside the h2 protocol handling itself. >=20 > Just my initial gut reaction... >=20 > -Stefan >=20 > > You have kind of let the cat out of the bag at just doing an h1 = connect. That's actually possible with the draft (or at least = envisioned) as I defined :protocol separate from the websocket specific = stuff... but I kinda hope to never speak of it again :) > > > > This is a tough one - its definitely going for simplicity as its = main goal.. that means ignoring many places that can be improved. That's = a choice based on > > a] the history of other efforts seem to suggest there is no stomach = for complexity/risk here > > b] we hear about this problem enough that I think its worth seeing = if this can be m ade a consensus mvp > > c] my belief that websockets is a transitional technology - it will = be around for years but some kind of native http will supplant it. > > > > ymmv (more than usual on this one!) > > > > -P > > > > > > > > > > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance = inside the tunneled connection, why don=E2=80=99t you just say that = you=E2=80=99re CONNECTing to an HTTP/1.1 tunnel? That=E2=80=99s then = treated as HTTP/1.1 over TCP, which is fully allowed to do Upgrade = itself. If you=E2=80=99re sure that=E2=80=99s the path you want, then = simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 inside = the stream. Incidentally, that might be a nice alternative for dealing = with HTTP_1_1_REQUIRED responses, too! > > > > > > > > From: Patrick McManus [mailto:pmcmanus@mozilla.com] > > Sent: Monday, October 16, 2017 5:16 AM > > To: Andy Green > > Cc: Martin Thomson ; Patrick McManus = ; hybi ; Cory Benfield = ; Patrick McManus ; HTTP = Working Group > > Subject: Re: [hybi] New Version Notification for = draft-mcmanus-httpbis-h2-websockets-00.txt > > > > > > > > > > > > > > > > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green = wrote: > > > > > > You can probably pipeline the CONNECT + ws handshake though, Patrick = shows them sequentially and I didn't think about it myself. > > > > > > > > right. The example is just for clarity and cannot show all = expressions of h2 flows. > > > > > > > > CONNECT + DATA before the response headers is pretty much the h2 = analog of TCP Fast Open. The devil is in the details.. That's a general = CONNECT + DATA issue not limited to the protocol upgrade described here = so I don't think its worth discussion in a websockets rfc. > > > > > > > > I think the path to success here hinges on a very tight scoping of = work and therefore optimizing handshake latency is a non-goal of this = effort. > > > > > > > > > > > > Still only two round trips. > > > > > > - SETTINGS - SETTINGS > > - GET /index.html > > - 200 HEADERS + DATA > > > > - :method CONNECT > > - DATA ws handshake > > - 200 HEADERS > > - DATA ws handshake final > > - DATA... > > > > - DATA ... - DATA... > > > > With the part of the pipelining that is legal for ws, two round = trips before the client can start to send data and 1.5 before the server = can send data... if it's true then you're right it's not so bad. > > > > Were you concerned that the client needs to learn that the server > > supports websockets and not just :protocol? > > > > > > No I just followed Patrick's sequencing; he shows them serialized. = But you're right at least the CONNECT + ws handshake can probably be = pipelined. > > > > That's also going to be a variation from normal h2 HEADERS flow if I = understood it, on one stream there will be END_HEADERs coming twice (for = the CONNECT and the ws handshake separately) > > > > Anyway you are right, it makes any difference with PUSH_PROMISE = probably not worth the effort. > > > > -Andy > > > > > > > > >=20 >=20 From nobody Tue Oct 17 07:55:01 2017 Return-Path: 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 9BF76132F76 for ; Tue, 17 Oct 2017 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=Ae5QpfR3; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=IBgCSYeT 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 nruaPfJkD4Qn for ; Tue, 17 Oct 2017 07:54:59 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB72132F6C for ; Tue, 17 Oct 2017 07:54:59 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id A43AB15A361A; Tue, 17 Oct 2017 16:54:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508252097; bh=LgHASFy55BPs30jFd2leHrv5Ulh7CsXOLeLj5n9JXIc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ae5QpfR3IEgIXMjEO5q7aexCCR7exKXNqAqZvIXBfIq5mxy3Cz4N0YLPF1pyDFEjc KM2rTrhM2ZM/SkDEc5BU1BF57pubbdc5AV2dqaZF18nYgK/k+gY+tUOnOtn4hrGzLi 6DSdoElvOXvGyqKIK6qmgj8byuDZtzHpAGib9OWY= Received: from resistance.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 8515B15A021E; Tue, 17 Oct 2017 16:54:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508252096; bh=LgHASFy55BPs30jFd2leHrv5Ulh7CsXOLeLj5n9JXIc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IBgCSYeTO5+122p/qLKAa2B0NiS0vHlffpTNeljE79xCWY3Ea61UMO+NJCzuQwpUe vgXFHVEzuHlBGIu05gmxR1SLxRy+by6nUVrcOvKkRWrv58bTVzQfNQ98k4XMzpz4nV QtNA4v7NcGpY5lud2B6jlFzL7Io8dro82bs9Eqi8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Stefan Eissing In-Reply-To: Date: Tue, 17 Oct 2017 16:54:56 +0200 Cc: Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> <7ADE2BB9-BDE8-4FDC-BFA2-59D066D65067@greenbytes.de> To: Patrick McManus X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:55:00 -0000 Ah! Let's agree on newer, better, faster... In that context, I understand your objection. ^^ > Am 17.10.2017 um 16:48 schrieb Patrick McManus : >=20 > nothing about versions other than the name Upgrade :) >=20 >=20 > On Tue, Oct 17, 2017 at 10:40 AM, Stefan Eissing = wrote: >=20 >=20 > > Am 17.10.2017 um 16:38 schrieb Patrick McManus = : > > > > On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing = wrote: > > > > Me stupid. Me asking, why not :upgrade? > > > > > > because its not upgrading anything to a higher version. I'm sure = 6455 would have used a different name except they were reusing existing = h1 infrastructure. >=20 > rfc7230, ch. 6.7 >=20 > "The "Upgrade" header field is intended to provide a simple mechanism > for transitioning from HTTP/1.1 to some other protocol on the same > connection." >=20 > Nothing about version here. I do not mind another header name, but if = it does the same thing... >=20 > Cheers, >=20 > Stefan >=20 >=20 From nobody Tue Oct 17 08:00:24 2017 Return-Path: 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 4E889132FA7 for ; Tue, 17 Oct 2017 08:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 dcc3UpkFXptP for ; Tue, 17 Oct 2017 08:00:20 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0BC132D22 for ; Tue, 17 Oct 2017 08:00:13 -0700 (PDT) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id 380C63A0A5 for ; Tue, 17 Oct 2017 11:00:12 -0400 (EDT) Received: by mail-lf0-f42.google.com with SMTP id a16so2364842lfk.0 for ; Tue, 17 Oct 2017 08:00:12 -0700 (PDT) X-Gm-Message-State: AMCzsaXS4wZ18DMKTRHZZ+7FEmZzxR7n0ZjIMc/a4d1s84xxlrfxPjqO UHRFOFYS2iG5bM1F3rrZTn/AQEhbV7QEl/3OYHU= X-Google-Smtp-Source: ABhQp+SwOqXnSLD/YCLeEyGsQTQFj2zN3s+cq88iPUsXWVsyXDDWijjSQP8fYTnobii75UmzlERfX/5a2MkAcy54pu8= X-Received: by 10.46.84.84 with SMTP id y20mr1052153ljd.89.1508252410776; Tue, 17 Oct 2017 08:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Tue, 17 Oct 2017 08:00:09 -0700 (PDT) In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> From: Patrick McManus Date: Tue, 17 Oct 2017 11:00:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Stefan Eissing Cc: Patrick McManus , Mike Bishop , Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Content-Type: multipart/alternative; boundary="f403045fb58e2d1465055bbf61f1" Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 15:00:23 -0000 --f403045fb58e2d1465055bbf61f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable the concept is that CONNECT establishes a HTTP tunnel to a websockets server.. any websocket stuff happens in that tunnel, any HTTP stuff happens out at the CONNECT side (so that might be path, authority, cookies for CONNECT, and version subprotocol extensions and selected subprotocol in the tunnel..). That's the same flow as the current text, its just a simpler parser that doesn't drag h1 into things. Smooshing all the options onto the CONNECT (as they were with the 6455 GET) doesn't really have any perf benefit assuming you pipeline the DATA frames before the response HEADERS. (and I'll update the example to show that) On Tue, Oct 17, 2017 at 10:52 AM, Stefan Eissing < stefan.eissing@greenbytes.de> wrote: > Thanks for the poll! > > > Am 17.10.2017 um 16:34 schrieb Patrick McManus : > > > > Clearly substituting the h1 exchange out in favor of a new websockets > specific exchange that contained sub-protocol and version tokens would lo= ok > better on paper... I actually thought diverging from 6455 would make peop= le > LESS likely to implement. Maybe I'm wrong. > > > > So let's poll - please speak up if you have a ws impl (either client or > server): > > > > If the spec added a new websockets specific parameter negotiation and > removed the H1 syntax it would make me > > a] MORE likely to implement > > b] LESS likely to implement > > c] wouldn't change my behavior but I like it more > > d] wouldn't change my behavior but it would be more painful (or like i= t > less) > > e] really don't care at all. > > c) > > However, it is not really clear to me why we need another parameter > negotiation, > besides defining what rfc6455, ch. 4.2.1 means by "Upgrade" and > "Connection" header > requirements on a h2 stream. > > You most likely have more ws experience than myself, so please understand > this as a > real question for me and not some rhetoric hand-waving. > > To explain my pov: the h2 code sits on the connection/stream, will detect > the > to-be-defined equivalent of a "Upgrade: websocket" request header and fee= d > the server-internal, > proprietary websocket implementation all the information it desires. h1/h= 2 > protocol serialization > is basically over at this point. > > That is how I look at it. This might be totally different for other > peoples implementation, of course. > > > On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing < > stefan.eissing@greenbytes.de> wrote: > > > > > > > Am 16.10.2017 um 23:31 schrieb Patrick McManus = : > > > > > > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > > [...] > > > > > > I hear what you're saying.. but I think you're going a touch too far. > websocket means 6455 which has all that h1 stuff as part of its > configuration.. I think it would be totally fair to say such a server cou= ld > have a more constrained parser that failed any non-ws compliant handshake > even if it were valid h1. Mostly I think it becomes an insanely ugly what > to do websocket parameter exchange. > > > > > > I think of origin info (scheme and authority) more as keys to route > the CONNECT request.. it's :protocol that defines what to do in the tunne= l. > I admit I did consider calling it :alpn (which has a similar kind of > property.. its a route of sorts but it doesn't bear the SETTINGS or magic > of h2) > > > > Me stupid. Me asking, why not :upgrade? > > > > ht;dr (have time, do read) > > > > As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this > stream from now on, afaict. > > > > >From a server implementation pov that opens a larger can of worms. It > would mean warming up the HTTP/1.1 engine for the DATA on this stream. Th= at > needs some extra care so that it does only safe things inside a h2 stream= . > On first glance, it seems to be easier and safer to do the stream :upgrad= e > inside the h2 protocol handling itself. > > > > Just my initial gut reaction... > > > > -Stefan > > > > > You have kind of let the cat out of the bag at just doing an h1 > connect. That's actually possible with the draft (or at least envisioned) > as I defined :protocol separate from the websocket specific stuff... but = I > kinda hope to never speak of it again :) > > > > > > This is a tough one - its definitely going for simplicity as its main > goal.. that means ignoring many places that can be improved. That's a > choice based on > > > a] the history of other efforts seem to suggest there is no stomach > for complexity/risk here > > > b] we hear about this problem enough that I think its worth seeing i= f > this can be m ade a consensus mvp > > > c] my belief that websockets is a transitional technology - it will > be around for years but some kind of native http will supplant it. > > > > > > ymmv (more than usual on this one!) > > > > > > -P > > > > > > > > > > > > > > > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance = inside > the tunneled connection, why don=E2=80=99t you just say that you=E2=80=99= re CONNECTing to > an HTTP/1.1 tunnel? That=E2=80=99s then treated as HTTP/1.1 over TCP, wh= ich is > fully allowed to do Upgrade itself. If you=E2=80=99re sure that=E2=80=99= s the path you > want, then simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/= 1.1 inside > the stream. Incidentally, that might be a nice alternative for dealing > with HTTP_1_1_REQUIRED responses, too! > > > > > > > > > > > > From: Patrick McManus [mailto:pmcmanus@mozilla.com] > > > Sent: Monday, October 16, 2017 5:16 AM > > > To: Andy Green > > > Cc: Martin Thomson ; Patrick McManus < > pmcmanus@mozilla.com>; hybi ; Cory Benfield < > cory@lukasa.co.uk>; Patrick McManus ; HTTP Working > Group > > > Subject: Re: [hybi] New Version Notification for > draft-mcmanus-httpbis-h2-websockets-00.txt > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green wrote= : > > > > > > > > > You can probably pipeline the CONNECT + ws handshake though, Patrick > shows them sequentially and I didn't think about it myself. > > > > > > > > > > > > right. The example is just for clarity and cannot show all expression= s > of h2 flows. > > > > > > > > > > > > CONNECT + DATA before the response headers is pretty much the h2 > analog of TCP Fast Open. The devil is in the details.. That's a general > CONNECT + DATA issue not limited to the protocol upgrade described here s= o > I don't think its worth discussion in a websockets rfc. > > > > > > > > > > > > I think the path to success here hinges on a very tight scoping of > work and therefore optimizing handshake latency is a non-goal of this > effort. > > > > > > > > > > > > > > > > > > Still only two round trips. > > > > > > > > > - SETTINGS - SETTINGS > > > - GET /index.html > > > - 200 HEADERS + DATA > > > > > > - :method CONNECT > > > - DATA ws handshake > > > - 200 HEADERS > > > - DATA ws handshake final > > > - DATA... > > > > > > - DATA ... - DATA... > > > > > > With the part of the pipelining that is legal for ws, two round trips > before the client can start to send data and 1.5 before the server can se= nd > data... if it's true then you're right it's not so bad. > > > > > > Were you concerned that the client needs to learn that the server > > > supports websockets and not just :protocol? > > > > > > > > > No I just followed Patrick's sequencing; he shows them serialized. > But you're right at least the CONNECT + ws handshake can probably be > pipelined. > > > > > > That's also going to be a variation from normal h2 HEADERS flow if I > understood it, on one stream there will be END_HEADERs coming twice (for > the CONNECT and the ws handshake separately) > > > > > > Anyway you are right, it makes any difference with PUSH_PROMISE > probably not worth the effort. > > > > > > -Andy > > > > > > > > > > > > > > > > > > --f403045fb58e2d1465055bbf61f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
the concept is that CONNECT establishes a HTTP tunnel= to a websockets server.. any websocket stuff happens in that tunnel, any H= TTP stuff happens out at the CONNECT side (so that might be path, authority= , cookies for CONNECT, and version subprotocol extensions and selected subp= rotocol in the tunnel..). That's the same flow as the current text, its= just a simpler parser that doesn't drag h1 into things. Smooshing all = the options onto the CONNECT (as they were with the 6455 GET) doesn't r= eally have any perf benefit assuming you pipeline the DATA frames before th= e response HEADERS. (and I'll update the example to show that)



On Tue, Oct 17, 2017 at 10:52 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
Thanks for the poll!

> Am 17.10.2017 um 16:34 schrieb Patrick McManus <pmcmanus@mozilla.com>:
>
> Clearly substituting the h1 exchange out in favor of a new websockets = specific exchange that contained sub-protocol and version tokens would look= better on paper... I actually thought diverging from 6455 would make peopl= e LESS likely to implement. Maybe I'm wrong.
>
> So let's poll - please speak up if you have a ws impl (either clie= nt or server):
>
> If the spec added a new websockets specific parameter negotiation and = removed the H1 syntax it would make me
>=C2=A0 a] MORE likely to implement
>=C2=A0 b] LESS likely to implement
>=C2=A0 c] wouldn't change my behavior but I like it more
>=C2=A0 d] wouldn't change my behavior but it would be more painful = (or like it less)
>=C2=A0 e] really don't care at all.

c)

However, it is not really clear to me why we need another parameter negotia= tion,
besides defining what rfc6455, ch. 4.2.1 means by "Upgrade" and &= quot;Connection" header
requirements on a h2 stream.

You most likely have more ws experience than myself, so please understand t= his as a
real question for me and not some rhetoric hand-waving.

To explain my pov: the h2 code sits on the connection/stream, will detect t= he
to-be-defined equivalent of a "Upgrade: websocket" request header= and feed the server-internal,
proprietary websocket implementation all the information it desires. h1/h2 = protocol serialization
is basically over at this point.

That is how I look at it. This might be totally different for other peoples= implementation, of course.

> On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: >
>
> > Am 16.10.2017 um 23:31 schrieb Patrick McManus <pmcmanus@mozilla.com>:
> >
> > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:=
> [...]
> >
> > I hear what you're saying.. but I think you're going a to= uch too far. websocket means 6455 which has all that h1 stuff as part of it= s configuration.. I think it would be totally fair to say such a server cou= ld have a more constrained parser that failed any non-ws compliant handshak= e even if it were valid h1. Mostly I think it becomes an insanely ugly what= to do websocket parameter exchange.
> >
> > I think of origin info (scheme and authority) more as keys to rou= te the CONNECT request.. it's :protocol that defines what to do in the = tunnel. I admit I did consider calling it :alpn (which has a similar kind o= f property.. its a route of sorts but it doesn't bear the SETTINGS or m= agic of h2)
>
> Me stupid. Me asking, why not :upgrade?
>
> ht;dr (have time, do read)
>
> As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on thi= s stream from now on, afaict.
>
> >From a server implementation pov that opens a larger can of worms.= It would mean warming up the HTTP/1.1 engine for the DATA on this stream. = That needs some extra care so that it does only safe things inside a h2 str= eam. On first glance, it seems to be easier and safer to do the stream :upg= rade inside the h2 protocol handling itself.
>
> Just my initial gut reaction...
>
> -Stefan
>
> > You have kind of let the cat out of the bag at just doing an h1 c= onnect. That's actually possible with the draft (or at least envisioned= ) as I defined :protocol separate from the websocket specific stuff... but = I kinda hope to never speak of it again :)
> >
> > This is a tough one - its definitely going for simplicity as its = main goal.. that means ignoring many places that can be improved. That'= s a choice based on
> >=C2=A0 a] the history of other efforts seem to suggest there is no= stomach for complexity/risk here
> >=C2=A0 b] we hear about this problem enough that I think its worth= seeing if this can be m ade a consensus mvp
> >=C2=A0 c] my belief that websockets is a transitional technology -= it will be around for years but some kind of native http will supplant it.=
> >
> > ymmv (more than usual on this one!)
> >
> > -P
> >
> >
> >
> >
> > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets da= nce inside the tunneled connection, why don=E2=80=99t you just say that you= =E2=80=99re CONNECTing to an HTTP/1.1 tunnel?=C2=A0 That=E2=80=99s then tre= ated as HTTP/1.1 over TCP, which is fully allowed to do Upgrade itself.=C2= =A0 If you=E2=80=99re sure that=E2=80=99s the path you want, then simply sa= y in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 inside the stream.= =C2=A0 Incidentally, that might be a nice alternative for dealing with HTTP= _1_1_REQUIRED responses, too!
> >
> >
> >
> > From: Patrick McManus [mailto:pmcmanus@mozilla.com]
> > Sent: Monday, October 16, 2017 5:16 AM
> > To: Andy Green <andy@warmc= at.com>
> > Cc: Martin Thomson <martin.thomson@gmail.com>; Patrick McManus <pmcmanus@mozilla.com>; hybi <hybi@ietf.org>; Cory Benfield <cory@lukasa.co.uk>; Patrick McManus <mcmanus@ducksong.com>; HTTP Working= Group <ietf-http-wg@w3.org&g= t;
> > Subject: Re: [hybi] New Version Notification for draft-mcmanus-ht= tpbis-h2-websockets-00.txt
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <andy@warmcat.com> wrote:
> >
> >
> > You can probably pipeline the CONNECT + ws handshake though, Patr= ick shows them sequentially and I didn't think about it myself.
> >
> >
> >
> > right. The example is just for clarity and cannot show all expres= sions of h2 flows.
> >
> >
> >
> > CONNECT + DATA before the response headers is pretty much the h2 = analog of TCP Fast Open. The devil is in the details.. That's a general= CONNECT + DATA issue not limited to the protocol upgrade described here so= I don't think its worth discussion in a websockets rfc.
> >
> >
> >
> > I think the path to success here hinges on a very tight scoping o= f work and therefore optimizing handshake latency is a non-goal of this eff= ort.
> >
> >
> >
> >
> >
> > Still only two round trips.
> >
> >
> >=C2=A0 - SETTINGS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 - SETTINGS
> >=C2=A0 - GET /index.html
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 2= 00 HEADERS + DATA
> >
> >=C2=A0 - :method CONNECT
> >=C2=A0 - DATA ws handshake
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- 200 HEADERS
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- DATA ws handshake final
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- DATA...
> >
> >=C2=A0 - DATA ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-= DATA...
> >
> > With the part of the pipelining that is legal for ws, two round t= rips before the client can start to send data and 1.5 before the server can= send data... if it's true then you're right it's not so bad. > >
> > Were you concerned that the client needs to learn that the server=
> > supports websockets and not just :protocol?
> >
> >
> > No I just followed Patrick's sequencing; he shows them serial= ized.=C2=A0 But you're right at least the CONNECT + ws handshake can pr= obably be pipelined.
> >
> > That's also going to be a variation from normal h2 HEADERS fl= ow if I understood it, on one stream there will be END_HEADERs coming twice= (for the CONNECT and the ws handshake separately)
> >
> > Anyway you are right, it makes any difference with PUSH_PROMISE p= robably not worth the effort.
> >
> > -Andy
> >
> >
> >
> >
>
>


--f403045fb58e2d1465055bbf61f1-- From nobody Tue Oct 17 09:34:00 2017 Return-Path: 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 E0A5813307E for ; Tue, 17 Oct 2017 09:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 apXjUXmTHEe5 for ; Tue, 17 Oct 2017 09:33:53 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0109.outbound.protection.outlook.com [104.47.36.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E15134239 for ; Tue, 17 Oct 2017 09:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CXO1PqDeUH85kreqw49+MGfgYe3TPnYghRvXKtq1fOk=; b=mRmmjoAiNgtPL+XGqsoKXVxJSdFHU8BkaRw7V0zw++pZITnSQqGtlPk/7cvEMWgPWhdDP0aPpqiIBr8KKGQjSYpj5tcVMjM3G1RnWTLiT6xqmEnhU5/+kkuKfOUHzjz62tD0xmdxoQKj8zJxY3Nu1x/6e5WN9THN2rz6FXxY95E= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0189.namprd21.prod.outlook.com (10.173.52.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Tue, 17 Oct 2017 16:33:46 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0178.002; Tue, 17 Oct 2017 16:33:45 +0000 From: Mike Bishop To: Patrick McManus , Stefan Eissing CC: Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Thread-Topic: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt Thread-Index: AQHTRnkXSa3fJMYEE0KGC67TZNNyA6LmtAUggABLXYCAAMADgIAAXa0AgAAcXDA= Date: Tue, 17 Oct 2017 16:33:45 +0000 Message-ID: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8::659] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0189; 6:bk2k2aXn0Xsg86/pcMcGSSlC4mpQPaiZjJm9zPNVacd9uk7tM82cBHDAULjKp4p8L/IhQRsqxc4MfN7i93ehA0SmCBmIxo1QclBppIsmF6sEcQXn+zOF4u1EA7lC3kDtCdAQ1zfacE+f8Bgj6uil7NJlKUFUF/dnGhisciddCoZH52GXuO+/TpPXMuGDcfR5fXu+q03NfjXZGUhPsTLa/x8xODiGSLq25WUIa2r92FyWtJ99Yej2wRxEaN0Uh+9cDCtn5EfqzkZzzIqw8qIPfxamxHkyZJMiDvaw3xH9donET6ao4E8FgK8c2BcbkYBAdh2lx6xV1w0kcDoPwkUvFSYPyk8gd9Iq6xgOzEeLzcA=; 5:/gKHSOZ2eI+EPn5OTdbocGjyfOXDokWBxNV0tEI4c5OF5OlF9zBtE/pczJwjpfiQ393DTLv06X2iaNYfmL8i5JNk12CJPGtrr30zfjBGiyxXzYKj08jXyvCtaBmqfihO/mmkMHoaBXY19KgDf4cR5AHhGVZHA62nPsY1LVO5dwc=; 24:eAt+F1g0YJD+SzGvNReyH8OMlsQg0f6uu+YNgXj21yNpDjZUi4s5dIW64G/FQvsfPxsqnfq+J6gr036G30uvsctRDWza836m2oIDLrThO6c=; 7:Zr0s+7HKt8JxUx73w1bLiYAua1d08xfm6wWUQoPZJ3uS8xNb6Zenvhn8mAcNJpMEK0ejR7uhRasYSOu7ntn+sbZ44S3BnQgoyNCkC4LCq5VldBZL5E354mNfbnSa9WpsZFO8DEzaYVaZGmaQaoXNNdKeFVVGiNbNttlN+x5KPPLuq8YxdnVZxwIyIgGiLrJ3fpu7gitE6iUjgZdsNDV/H+Da3euiYzk23h7EbX8f0ro9/FGSLMptlRwA62LV2Kay x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 37ee17c0-84f2-4c6a-dcb6-08d5157cd664 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603219)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0189; x-ms-traffictypediagnostic: MWHPR21MB0189: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(100405760836317)(21748063052155)(21532816269658)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0189; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0189; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(47760400005)(199003)(377454003)(24454002)(189002)(81156014)(81166006)(10710500007)(53936002)(106356001)(7736002)(316002)(2906002)(5660300001)(6246003)(86612001)(3660700001)(25786009)(22452003)(101416001)(53546010)(3280700002)(54896002)(54356999)(50986999)(76176999)(6306002)(790700001)(74316002)(236005)(102836003)(6116002)(55016002)(7696004)(99286003)(8936002)(8676002)(97736004)(9686003)(33656002)(110136005)(54906003)(105586002)(10090500001)(68736007)(39060400002)(2900100001)(4326008)(86362001)(72206003)(6436002)(7110500001)(6506006)(8990500004)(347745004)(229853002)(10290500003)(478600001)(2950100002)(189998001)(2420400007)(15650500001)(77096006)(19609705001)(14454004)(230783001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0189; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01415F7DABA1F6804AFD2669874C0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37ee17c0-84f2-4c6a-dcb6-08d5157cd664 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 16:33:45.7873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0189 Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:33:59 -0000 --_000_MWHPR21MB01415F7DABA1F6804AFD2669874C0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBzb21ld2hhdCBjb25qZWN0dXJlLCBzaW5jZSBJIGhhdmVu4oCZdCBnb25lIG92ZXIg aXQgd2l0aCBvdXIgZGV2IHRlYW0sIGJ1dCBJIHRoaW5rIGl0IHBsYXlzIG91dCB0byAoYykuICBX ZeKAmXZlIGhhZCBlbm91Z2ggcGVvcGxlIGFzayBmb3IgV2ViU29ja2V0IHN1cHBvcnQsIGl0IHdp bGwgZXZlbnR1YWxseSBoYXBwZW4gaWYgdGhlcmXigJlzIGFuIGludGVyb3BlcmFibGUgd2F5IHRv IGRvIGl0LiAgSUlSQywgVXBncmFkZSBpcyBwbHVnZ2FibGUuIFdoZW4gYSBwcm90b2NvbCB1cGdy YWRlcyB0byB3ZWJzb2NrZXQsIHdlIGNoZWNrIGlmIHRoZXJl4oCZcyBhIGhhbmRsZXIgZm9yIHRo YXQgcHJvdG9jb2wuICBJZiBzbywgd2UgcmV0dXJuIDEwMSBhbmQgZ2l2ZSBjb250cm9sIG9mIHRo ZSBUQ1AgY29ubmVjdGlvbiB0byB0aGF0IGhhbmRsZXI7IHRoZSBIVFRQIGxheWVyIGJlY29tZXMg cGFzc3Rocm91Z2guDQoNCklmIHdlIGhhdmUgdG8gc3VwcG9ydCBwdWxsaW5nIGluIEhUVFAvMS4x IHBhcnNpbmcgdG8gdGhhdCBzdHJlYW0gc2ltcGx5IHRvIGRvIGFuIFVwZ3JhZGUsIHRoYXTigJlz IGFuIGFkZGl0aW9uYWwgc2NlbmFyaW8gd2UgaGF2ZSB0byBzdXBwb3J0IGluLWxpbmUgZmlyc3Qs IGFuZCBhbiBleHRyYSBsYXllciB0byBnbyBwYXNzdGhyb3VnaCBpbiB0aGUgaG9wZWZ1bGx5LWNv bW1vbiBjYXNlLiAgSeKAmWQgcmF0aGVyIGJlIGFibGUgdG8gaGFuZCB0aGUgc3RyZWFtIGRpcmVj dGx5IHRvIHRoZSBXZWJTb2NrZXQgbGlicmFyeSAob3duZWQgYnkgYSBkaWZmZXJlbnQgdGVhbSkg YW5kIGJlIGRvbmUsIGV2ZW4gaWYgaXQgbWVhbnMgdGhlcmXigJlzIGFuIEgyLXNwZWNpZmljIFVw Z3JhZGUgcGF0aC4gIChXaGljaCwgaXQgdHVybnMgb3V0LCB0aGVyZSBpcyBpbiB0aGlzIGRyYWZ0 IGFscmVhZHkuKQ0KDQpXZSBjb3VsZCBzdGlsbCBkZWNpZGUgdG8gc3VwcG9ydCBIMi3igJx1cGdy YWRl4oCdLXRvLUgxIGluIHRoZSBmdXR1cmUsIGJ1dCBpdCB3b3VsZCBiZSBiZWNhdXNlIHRoYXTi gJlzIGEgZmVhdHVyZSB3ZSBmb3VuZCB3ZSBuZWVkZWQgZm9yIHNvbWUgcmVhc29uLCBub3QgYmVj YXVzZSBpdCB3YXMgYW4gYW5ub3lpbmcgc3RlcHBpbmctc3RvbmUgdG8gc29tZXRoaW5nIHdlIGFj dHVhbGx5IHdhbnRlZC4gIChJbiBmYWN0LCBvdXIgbW9zdCBjb21tb24gcmVhc29uIHRvIGlzc3Vl IEhUVFBfMV8xX1JFUVVJUkVEIGlzIGNsaWVudCBjZXJ0aWZpY2F0ZXMsIHdoaWNoIHRoaXMgd29u 4oCZdCBoZWxwLikNCg0KRnJvbTogUGF0cmljayBNY01hbnVzIFttYWlsdG86cG1jbWFudXNAbW96 aWxsYS5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE3LCAyMDE3IDc6MzQgQU0NClRvOiBT dGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4NCkNjOiBQYXRyaWNr IE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb20+OyBBbmR5IEdyZWVuIDxhbmR5QHdhcm1jYXQuY29tPjsgTWFydGlu IFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IGh5YmkgPGh5YmlAaWV0Zi5vcmc+ OyBDb3J5IEJlbmZpZWxkIDxjb3J5QGx1a2FzYS5jby51az47IE1jTWFudXMgUGF0cmljayA8bWNt YW51c0BkdWNrc29uZy5jb20+OyBIVFRQIFdvcmtpbmcgR3JvdXAgPGlldGYtaHR0cC13Z0B3My5v cmc+DQpTdWJqZWN0OiBSZTogW2h5YmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtbWNtYW51cy1odHRwYmlzLWgyLXdlYnNvY2tldHMtMDAudHh0DQoNCkNsZWFybHkgc3Vic3Rp dHV0aW5nIHRoZSBoMSBleGNoYW5nZSBvdXQgaW4gZmF2b3Igb2YgYSBuZXcgd2Vic29ja2V0cyBz cGVjaWZpYyBleGNoYW5nZSB0aGF0IGNvbnRhaW5lZCBzdWItcHJvdG9jb2wgYW5kIHZlcnNpb24g dG9rZW5zIHdvdWxkIGxvb2sgYmV0dGVyIG9uIHBhcGVyLi4uIEkgYWN0dWFsbHkgdGhvdWdodCBk aXZlcmdpbmcgZnJvbSA2NDU1IHdvdWxkIG1ha2UgcGVvcGxlIExFU1MgbGlrZWx5IHRvIGltcGxl bWVudC4gTWF5YmUgSSdtIHdyb25nLg0KDQpTbyBsZXQncyBwb2xsIC0gcGxlYXNlIHNwZWFrIHVw IGlmIHlvdSBoYXZlIGEgd3MgaW1wbCAoZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIpOg0KDQpJZiB0 aGUgc3BlYyBhZGRlZCBhIG5ldyB3ZWJzb2NrZXRzIHNwZWNpZmljIHBhcmFtZXRlciBuZWdvdGlh dGlvbiBhbmQgcmVtb3ZlZCB0aGUgSDEgc3ludGF4IGl0IHdvdWxkIG1ha2UgbWUNCiBhXSBNT1JF IGxpa2VseSB0byBpbXBsZW1lbnQNCiBiXSBMRVNTIGxpa2VseSB0byBpbXBsZW1lbnQNCiBjXSB3 b3VsZG4ndCBjaGFuZ2UgbXkgYmVoYXZpb3IgYnV0IEkgbGlrZSBpdCBtb3JlDQogZF0gd291bGRu J3QgY2hhbmdlIG15IGJlaGF2aW9yIGJ1dCBpdCB3b3VsZCBiZSBtb3JlIHBhaW5mdWwgKG9yIGxp a2UgaXQgbGVzcykNCiBlXSByZWFsbHkgZG9uJ3QgY2FyZSBhdCBhbGwuDQoNCk9uIFR1ZSwgT2N0 IDE3LCAyMDE3IGF0IDQ6NTggQU0sIFN0ZWZhbiBFaXNzaW5nIDxzdGVmYW4uZWlzc2luZ0BncmVl bmJ5dGVzLmRlPG1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPj4gd3JvdGU6DQoN Cg0KPiBBbSAxNi4xMC4yMDE3IHVtIDIzOjMxIHNjaHJpZWIgUGF0cmljayBNY01hbnVzIDxwbWNt YW51c0Btb3ppbGxhLmNvbTxtYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb20+PjoNCj4NCj4gT24g TW9uLCBPY3QgMTYsIDIwMTcgYXQgMToxMyBQTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNClsuLi5dDQo+DQo+IEkgaGVhciB3aGF0IHlvdSdyZSBzYXlpbmcuLiBidXQgSSB0aGluayB5 b3UncmUgZ29pbmcgYSB0b3VjaCB0b28gZmFyLiB3ZWJzb2NrZXQgbWVhbnMgNjQ1NSB3aGljaCBo YXMgYWxsIHRoYXQgaDEgc3R1ZmYgYXMgcGFydCBvZiBpdHMgY29uZmlndXJhdGlvbi4uIEkgdGhp bmsgaXQgd291bGQgYmUgdG90YWxseSBmYWlyIHRvIHNheSBzdWNoIGEgc2VydmVyIGNvdWxkIGhh dmUgYSBtb3JlIGNvbnN0cmFpbmVkIHBhcnNlciB0aGF0IGZhaWxlZCBhbnkgbm9uLXdzIGNvbXBs aWFudCBoYW5kc2hha2UgZXZlbiBpZiBpdCB3ZXJlIHZhbGlkIGgxLiBNb3N0bHkgSSB0aGluayBp dCBiZWNvbWVzIGFuIGluc2FuZWx5IHVnbHkgd2hhdCB0byBkbyB3ZWJzb2NrZXQgcGFyYW1ldGVy IGV4Y2hhbmdlLg0KPg0KPiBJIHRoaW5rIG9mIG9yaWdpbiBpbmZvIChzY2hlbWUgYW5kIGF1dGhv cml0eSkgbW9yZSBhcyBrZXlzIHRvIHJvdXRlIHRoZSBDT05ORUNUIHJlcXVlc3QuLiBpdCdzIDpw cm90b2NvbCB0aGF0IGRlZmluZXMgd2hhdCB0byBkbyBpbiB0aGUgdHVubmVsLiBJIGFkbWl0IEkg ZGlkIGNvbnNpZGVyIGNhbGxpbmcgaXQgOmFscG4gKHdoaWNoIGhhcyBhIHNpbWlsYXIga2luZCBv ZiBwcm9wZXJ0eS4uIGl0cyBhIHJvdXRlIG9mIHNvcnRzIGJ1dCBpdCBkb2Vzbid0IGJlYXIgdGhl IFNFVFRJTkdTIG9yIG1hZ2ljIG9mIGgyKQ0KDQpNZSBzdHVwaWQuIE1lIGFza2luZywgd2h5IG5v dCA6dXBncmFkZT8NCg0KaHQ7ZHIgKGhhdmUgdGltZSwgZG8gcmVhZCkNCg0KQXMgcHJvcG9zZWQs IHRoZSBDT05OTkVDVCBzZWVtcyB0byBzYXk6IGxldCdzIHRhbGsgSFRUUC8xLjEgb24gdGhpcyBz dHJlYW0gZnJvbSBub3cgb24sIGFmYWljdC4NCg0KRnJvbSBhIHNlcnZlciBpbXBsZW1lbnRhdGlv biBwb3YgdGhhdCBvcGVucyBhIGxhcmdlciBjYW4gb2Ygd29ybXMuIEl0IHdvdWxkIG1lYW4gd2Fy bWluZyB1cCB0aGUgSFRUUC8xLjEgZW5naW5lIGZvciB0aGUgREFUQSBvbiB0aGlzIHN0cmVhbS4g VGhhdCBuZWVkcyBzb21lIGV4dHJhIGNhcmUgc28gdGhhdCBpdCBkb2VzIG9ubHkgc2FmZSB0aGlu Z3MgaW5zaWRlIGEgaDIgc3RyZWFtLiBPbiBmaXJzdCBnbGFuY2UsIGl0IHNlZW1zIHRvIGJlIGVh c2llciBhbmQgc2FmZXIgdG8gZG8gdGhlIHN0cmVhbSA6dXBncmFkZSBpbnNpZGUgdGhlIGgyIHBy b3RvY29sIGhhbmRsaW5nIGl0c2VsZi4NCg0KSnVzdCBteSBpbml0aWFsIGd1dCByZWFjdGlvbi4u Lg0KDQotU3RlZmFuDQoNCj4gWW91IGhhdmUga2luZCBvZiBsZXQgdGhlIGNhdCBvdXQgb2YgdGhl IGJhZyBhdCBqdXN0IGRvaW5nIGFuIGgxIGNvbm5lY3QuIFRoYXQncyBhY3R1YWxseSBwb3NzaWJs ZSB3aXRoIHRoZSBkcmFmdCAob3IgYXQgbGVhc3QgZW52aXNpb25lZCkgYXMgSSBkZWZpbmVkIDpw cm90b2NvbCBzZXBhcmF0ZSBmcm9tIHRoZSB3ZWJzb2NrZXQgc3BlY2lmaWMgc3R1ZmYuLi4gYnV0 IEkga2luZGEgaG9wZSB0byBuZXZlciBzcGVhayBvZiBpdCBhZ2FpbiA6KQ0KPg0KPiBUaGlzIGlz IGEgdG91Z2ggb25lIC0gaXRzIGRlZmluaXRlbHkgZ29pbmcgZm9yIHNpbXBsaWNpdHkgYXMgaXRz IG1haW4gZ29hbC4uIHRoYXQgbWVhbnMgaWdub3JpbmcgbWFueSBwbGFjZXMgdGhhdCBjYW4gYmUg aW1wcm92ZWQuIFRoYXQncyBhIGNob2ljZSBiYXNlZCBvbg0KPiAgYV0gdGhlIGhpc3Rvcnkgb2Yg b3RoZXIgZWZmb3J0cyBzZWVtIHRvIHN1Z2dlc3QgdGhlcmUgaXMgbm8gc3RvbWFjaCBmb3IgY29t cGxleGl0eS9yaXNrIGhlcmUNCj4gIGJdIHdlIGhlYXIgYWJvdXQgdGhpcyBwcm9ibGVtIGVub3Vn aCB0aGF0IEkgdGhpbmsgaXRzIHdvcnRoIHNlZWluZyBpZiB0aGlzIGNhbiBiZSBtIGFkZSBhIGNv bnNlbnN1cyBtdnANCj4gIGNdIG15IGJlbGllZiB0aGF0IHdlYnNvY2tldHMgaXMgYSB0cmFuc2l0 aW9uYWwgdGVjaG5vbG9neSAtIGl0IHdpbGwgYmUgYXJvdW5kIGZvciB5ZWFycyBidXQgc29tZSBr aW5kIG9mIG5hdGl2ZSBodHRwIHdpbGwgc3VwcGxhbnQgaXQuDQo+DQo+IHltbXYgKG1vcmUgdGhh biB1c3VhbCBvbiB0aGlzIG9uZSEpDQo+DQo+IC1QDQo+DQo+DQo+DQo+DQo+IEdpdmVuIHRoYXQg eW914oCZcmUgZG9pbmcgdGhlIGZ1bGwgVXBncmFkZS10by1XZWJTb2NrZXRzIGRhbmNlIGluc2lk ZSB0aGUgdHVubmVsZWQgY29ubmVjdGlvbiwgd2h5IGRvbuKAmXQgeW91IGp1c3Qgc2F5IHRoYXQg eW914oCZcmUgQ09OTkVDVGluZyB0byBhbiBIVFRQLzEuMSB0dW5uZWw/ICBUaGF04oCZcyB0aGVu IHRyZWF0ZWQgYXMgSFRUUC8xLjEgb3ZlciBUQ1AsIHdoaWNoIGlzIGZ1bGx5IGFsbG93ZWQgdG8g ZG8gVXBncmFkZSBpdHNlbGYuICBJZiB5b3XigJlyZSBzdXJlIHRoYXTigJlzIHRoZSBwYXRoIHlv dSB3YW50LCB0aGVuIHNpbXBseSBzYXkgaW4gdGhlIEhUVFAvMiBsYXllciB0aGF0IHlvdeKAmXJl IGRvaW5nIEhUVFAvMS4xIGluc2lkZSB0aGUgc3RyZWFtLiAgSW5jaWRlbnRhbGx5LCB0aGF0IG1p Z2h0IGJlIGEgbmljZSBhbHRlcm5hdGl2ZSBmb3IgZGVhbGluZyB3aXRoIEhUVFBfMV8xX1JFUVVJ UkVEIHJlc3BvbnNlcywgdG9vIQ0KPg0KPg0KPg0KPiBGcm9tOiBQYXRyaWNrIE1jTWFudXMgW21h aWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbTxtYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb20+XQ0K PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTYsIDIwMTcgNToxNiBBTQ0KPiBUbzogQW5keSBHcmVl biA8YW5keUB3YXJtY2F0LmNvbTxtYWlsdG86YW5keUB3YXJtY2F0LmNvbT4+DQo+IENjOiBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+PjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbTxtYWls dG86cG1jbWFudXNAbW96aWxsYS5jb20+PjsgaHliaSA8aHliaUBpZXRmLm9yZzxtYWlsdG86aHli aUBpZXRmLm9yZz4+OyBDb3J5IEJlbmZpZWxkIDxjb3J5QGx1a2FzYS5jby51azxtYWlsdG86Y29y eUBsdWthc2EuY28udWs+PjsgUGF0cmljayBNY01hbnVzIDxtY21hbnVzQGR1Y2tzb25nLmNvbTxt YWlsdG86bWNtYW51c0BkdWNrc29uZy5jb20+PjsgSFRUUCBXb3JraW5nIEdyb3VwIDxpZXRmLWh0 dHAtd2dAdzMub3JnPG1haWx0bzppZXRmLWh0dHAtd2dAdzMub3JnPj4NCj4gU3ViamVjdDogUmU6 IFtoeWJpXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1jbWFudXMtaHR0cGJp cy1oMi13ZWJzb2NrZXRzLTAwLnR4dA0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBPbiBNb24sIE9j dCAxNiwgMjAxNyBhdCAxMjo0NCBBTSwgQW5keSBHcmVlbiA8YW5keUB3YXJtY2F0LmNvbTxtYWls dG86YW5keUB3YXJtY2F0LmNvbT4+IHdyb3RlOg0KPg0KPg0KPiBZb3UgY2FuIHByb2JhYmx5IHBp cGVsaW5lIHRoZSBDT05ORUNUICsgd3MgaGFuZHNoYWtlIHRob3VnaCwgUGF0cmljayBzaG93cyB0 aGVtIHNlcXVlbnRpYWxseSBhbmQgSSBkaWRuJ3QgdGhpbmsgYWJvdXQgaXQgbXlzZWxmLg0KPg0K Pg0KPg0KPiByaWdodC4gVGhlIGV4YW1wbGUgaXMganVzdCBmb3IgY2xhcml0eSBhbmQgY2Fubm90 IHNob3cgYWxsIGV4cHJlc3Npb25zIG9mIGgyIGZsb3dzLg0KPg0KPg0KPg0KPiBDT05ORUNUICsg REFUQSBiZWZvcmUgdGhlIHJlc3BvbnNlIGhlYWRlcnMgaXMgcHJldHR5IG11Y2ggdGhlIGgyIGFu YWxvZyBvZiBUQ1AgRmFzdCBPcGVuLiBUaGUgZGV2aWwgaXMgaW4gdGhlIGRldGFpbHMuLiBUaGF0 J3MgYSBnZW5lcmFsIENPTk5FQ1QgKyBEQVRBIGlzc3VlIG5vdCBsaW1pdGVkIHRvIHRoZSBwcm90 b2NvbCB1cGdyYWRlIGRlc2NyaWJlZCBoZXJlIHNvIEkgZG9uJ3QgdGhpbmsgaXRzIHdvcnRoIGRp c2N1c3Npb24gaW4gYSB3ZWJzb2NrZXRzIHJmYy4NCj4NCj4NCj4NCj4gSSB0aGluayB0aGUgcGF0 aCB0byBzdWNjZXNzIGhlcmUgaGluZ2VzIG9uIGEgdmVyeSB0aWdodCBzY29waW5nIG9mIHdvcmsg YW5kIHRoZXJlZm9yZSBvcHRpbWl6aW5nIGhhbmRzaGFrZSBsYXRlbmN5IGlzIGEgbm9uLWdvYWwg b2YgdGhpcyBlZmZvcnQuDQo+DQo+DQo+DQo+DQo+DQo+IFN0aWxsIG9ubHkgdHdvIHJvdW5kIHRy aXBzLg0KPg0KPg0KPiAgLSBTRVRUSU5HUyAgICAgICAgICAgICAgICAgICAgICAtIFNFVFRJTkdT DQo+ICAtIEdFVCAvaW5kZXguaHRtbA0KPiAgICAgICAgICAgICAgICAgIC0gMjAwIEhFQURFUlMg KyBEQVRBDQo+DQo+ICAtIDptZXRob2QgQ09OTkVDVA0KPiAgLSBEQVRBIHdzIGhhbmRzaGFrZQ0K PiAgICAgICAgICAgICAgICAgICAtIDIwMCBIRUFERVJTDQo+ICAgICAgICAgICAgICAgICAgIC0g REFUQSB3cyBoYW5kc2hha2UgZmluYWwNCj4gICAgICAgICAgICAgICAgICAgLSBEQVRBLi4uDQo+ DQo+ICAtIERBVEEgLi4uICAgICAgICAgICAgIC0gREFUQS4uLg0KPg0KPiBXaXRoIHRoZSBwYXJ0 IG9mIHRoZSBwaXBlbGluaW5nIHRoYXQgaXMgbGVnYWwgZm9yIHdzLCB0d28gcm91bmQgdHJpcHMg YmVmb3JlIHRoZSBjbGllbnQgY2FuIHN0YXJ0IHRvIHNlbmQgZGF0YSBhbmQgMS41IGJlZm9yZSB0 aGUgc2VydmVyIGNhbiBzZW5kIGRhdGEuLi4gaWYgaXQncyB0cnVlIHRoZW4geW91J3JlIHJpZ2h0 IGl0J3Mgbm90IHNvIGJhZC4NCj4NCj4gV2VyZSB5b3UgY29uY2VybmVkIHRoYXQgdGhlIGNsaWVu dCBuZWVkcyB0byBsZWFybiB0aGF0IHRoZSBzZXJ2ZXINCj4gc3VwcG9ydHMgd2Vic29ja2V0cyBh bmQgbm90IGp1c3QgOnByb3RvY29sPw0KPg0KPg0KPiBObyBJIGp1c3QgZm9sbG93ZWQgUGF0cmlj aydzIHNlcXVlbmNpbmc7IGhlIHNob3dzIHRoZW0gc2VyaWFsaXplZC4gIEJ1dCB5b3UncmUgcmln aHQgYXQgbGVhc3QgdGhlIENPTk5FQ1QgKyB3cyBoYW5kc2hha2UgY2FuIHByb2JhYmx5IGJlIHBp cGVsaW5lZC4NCj4NCj4gVGhhdCdzIGFsc28gZ29pbmcgdG8gYmUgYSB2YXJpYXRpb24gZnJvbSBu b3JtYWwgaDIgSEVBREVSUyBmbG93IGlmIEkgdW5kZXJzdG9vZCBpdCwgb24gb25lIHN0cmVhbSB0 aGVyZSB3aWxsIGJlIEVORF9IRUFERVJzIGNvbWluZyB0d2ljZSAoZm9yIHRoZSBDT05ORUNUIGFu ZCB0aGUgd3MgaGFuZHNoYWtlIHNlcGFyYXRlbHkpDQo+DQo+IEFueXdheSB5b3UgYXJlIHJpZ2h0 LCBpdCBtYWtlcyBhbnkgZGlmZmVyZW5jZSB3aXRoIFBVU0hfUFJPTUlTRSBwcm9iYWJseSBub3Qg d29ydGggdGhlIGVmZm9ydC4NCj4NCj4gLUFuZHkNCj4NCj4NCj4NCj4NCg0K --_000_MWHPR21MB01415F7DABA1F6804AFD2669874C0MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBzb21ld2hhdCBj b25qZWN0dXJlLCBzaW5jZSBJIGhhdmVu4oCZdCBnb25lIG92ZXIgaXQgd2l0aCBvdXIgZGV2IHRl YW0sIGJ1dCBJIHRoaW5rIGl0IHBsYXlzIG91dCB0byAoYykuJm5ic3A7IFdl4oCZdmUgaGFkIGVu b3VnaCBwZW9wbGUgYXNrIGZvciBXZWJTb2NrZXQgc3VwcG9ydCwgaXQgd2lsbCBldmVudHVhbGx5 IGhhcHBlbiBpZiB0aGVyZeKAmXMgYW4gaW50ZXJvcGVyYWJsZSB3YXkgdG8gZG8gaXQuJm5ic3A7 IElJUkMsDQogVXBncmFkZSBpcyBwbHVnZ2FibGUuIFdoZW4gYSBwcm90b2NvbCB1cGdyYWRlcyB0 byB3ZWJzb2NrZXQsIHdlIGNoZWNrIGlmIHRoZXJl4oCZcyBhIGhhbmRsZXIgZm9yIHRoYXQgcHJv dG9jb2wuJm5ic3A7IElmIHNvLCB3ZSByZXR1cm4gMTAxIGFuZCBnaXZlIGNvbnRyb2wgb2YgdGhl IFRDUCBjb25uZWN0aW9uIHRvIHRoYXQgaGFuZGxlcjsgdGhlIEhUVFAgbGF5ZXIgYmVjb21lcyBw YXNzdGhyb3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgaGF2ZSB0byBzdXBwb3J0 IHB1bGxpbmcgaW4gSFRUUC8xLjEgcGFyc2luZyB0byB0aGF0IHN0cmVhbSBzaW1wbHkgdG8gZG8g YW4gVXBncmFkZSwgdGhhdOKAmXMgYW4gYWRkaXRpb25hbCBzY2VuYXJpbyB3ZSBoYXZlIHRvIHN1 cHBvcnQgaW4tbGluZSBmaXJzdCwgYW5kIGFuIGV4dHJhIGxheWVyIHRvIGdvIHBhc3N0aHJvdWdo IGluIHRoZSBob3BlZnVsbHktY29tbW9uIGNhc2UuJm5ic3A7IEnigJlkIHJhdGhlciBiZQ0KIGFi bGUgdG8gaGFuZCB0aGUgc3RyZWFtIGRpcmVjdGx5IHRvIHRoZSBXZWJTb2NrZXQgbGlicmFyeSAo b3duZWQgYnkgYSBkaWZmZXJlbnQgdGVhbSkgYW5kIGJlIGRvbmUsIGV2ZW4gaWYgaXQgbWVhbnMg dGhlcmXigJlzIGFuIEgyLXNwZWNpZmljIFVwZ3JhZGUgcGF0aC4mbmJzcDsgKFdoaWNoLCBpdCB0 dXJucyBvdXQsIHRoZXJlIGlzIGluIHRoaXMgZHJhZnQgYWxyZWFkeS4pPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlIGNvdWxkIHN0aWxsIGRlY2lkZSB0byBzdXBwb3J0IEgyLeKAnHVwZ3JhZGXi gJ0tdG8tSDEgaW4gdGhlIGZ1dHVyZSwgYnV0IGl0IHdvdWxkIGJlIGJlY2F1c2UNCjxpPnRoYXTi gJlzPC9pPiBhIGZlYXR1cmUgd2UgZm91bmQgd2UgbmVlZGVkIGZvciBzb21lIHJlYXNvbiwgbm90 IGJlY2F1c2UgaXQgd2FzIGFuIGFubm95aW5nIHN0ZXBwaW5nLXN0b25lIHRvIHNvbWV0aGluZyB3 ZSBhY3R1YWxseSB3YW50ZWQuJm5ic3A7IChJbiBmYWN0LCBvdXIgbW9zdCBjb21tb24gcmVhc29u IHRvIGlzc3VlIEhUVFBfMV8xX1JFUVVJUkVEIGlzIGNsaWVudCBjZXJ0aWZpY2F0ZXMsIHdoaWNo IHRoaXMgd29u4oCZdCBoZWxwLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFBhdHJpY2sgTWNNYW51cyBbbWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tXSA8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxNywgMjAxNyA3OjM0IEFNPGJyPg0KPGI+VG86PC9i PiBTdGVmYW4gRWlzc2luZyAmbHQ7c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSZndDs8YnI+ DQo8Yj5DYzo8L2I+IFBhdHJpY2sgTWNNYW51cyAmbHQ7cG1jbWFudXNAbW96aWxsYS5jb20mZ3Q7 OyBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IEFuZHkg R3JlZW4gJmx0O2FuZHlAd2FybWNhdC5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGlu LnRob21zb25AZ21haWwuY29tJmd0OzsgaHliaSAmbHQ7aHliaUBpZXRmLm9yZyZndDs7IENvcnkg QmVuZmllbGQgJmx0O2NvcnlAbHVrYXNhLmNvLnVrJmd0OzsgTWNNYW51cyBQYXRyaWNrICZsdDtt Y21hbnVzQGR1Y2tzb25nLmNvbSZndDs7DQogSFRUUCBXb3JraW5nIEdyb3VwICZsdDtpZXRmLWh0 dHAtd2dAdzMub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2h5YmldIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWNtYW51cy1odHRwYmlzLWgyLXdlYnNvY2tldHMt MDAudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xlYXJseSBzdWJz dGl0dXRpbmcgdGhlIGgxIGV4Y2hhbmdlIG91dCBpbiBmYXZvciBvZiBhIG5ldyB3ZWJzb2NrZXRz IHNwZWNpZmljIGV4Y2hhbmdlIHRoYXQgY29udGFpbmVkIHN1Yi1wcm90b2NvbCBhbmQgdmVyc2lv biB0b2tlbnMgd291bGQgbG9vayBiZXR0ZXIgb24gcGFwZXIuLi4gSSBhY3R1YWxseSB0aG91Z2h0 IGRpdmVyZ2luZyBmcm9tIDY0NTUgd291bGQgbWFrZSBwZW9wbGUgTEVTUyBsaWtlbHkgdG8NCiBp bXBsZW1lbnQuIE1heWJlIEknbSB3cm9uZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbGV0J3MgcG9sbCAtIHBsZWFzZSBzcGVhayB1cCBp ZiB5b3UgaGF2ZSBhIHdzIGltcGwgKGVpdGhlciBjbGllbnQgb3Igc2VydmVyKTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHNwZWMg YWRkZWQgYSBuZXcgd2Vic29ja2V0cyBzcGVjaWZpYyBwYXJhbWV0ZXIgbmVnb3RpYXRpb24gYW5k IHJlbW92ZWQgdGhlIEgxIHN5bnRheCBpdCB3b3VsZCBtYWtlIG1lPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDthXSBNT1JFIGxpa2VseSB0 byBpbXBsZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwO2JdIExFU1MgbGlrZWx5IHRvIGltcGxlbWVudDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Y10gd291bGRuJ3QgY2hh bmdlIG15IGJlaGF2aW9yIGJ1dCBJIGxpa2UgaXQgbW9yZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ZF0gd291bGRuJ3QgY2hhbmdlIG15 IGJlaGF2aW9yIGJ1dCBpdCB3b3VsZCBiZSBtb3JlIHBhaW5mdWwgKG9yIGxpa2UgaXQgbGVzcyk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw O2VdIHJlYWxseSBkb24ndCBjYXJlIGF0IGFsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMTcsIDIwMTcgYXQgNDo1OCBB TSwgU3RlZmFuIEVpc3NpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVl bmJ5dGVzLmRlIiB0YXJnZXQ9Il9ibGFuayI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCiZndDsgQW0gMTYuMTAuMjAxNyB1bSAyMzozMSBzY2hyaWViIFBh dHJpY2sgTWNNYW51cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tIj5w bWNtYW51c0Btb3ppbGxhLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1vbiwg T2N0IDE2LCAyMDE3IGF0IDE6MTMgUE0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NClsuLi5dPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBoZWFyIHdo YXQgeW91J3JlIHNheWluZy4uIGJ1dCBJIHRoaW5rIHlvdSdyZSBnb2luZyBhIHRvdWNoIHRvbyBm YXIuIHdlYnNvY2tldCBtZWFucyA2NDU1IHdoaWNoIGhhcyBhbGwgdGhhdCBoMSBzdHVmZiBhcyBw YXJ0IG9mIGl0cyBjb25maWd1cmF0aW9uLi4gSSB0aGluayBpdCB3b3VsZCBiZSB0b3RhbGx5IGZh aXIgdG8gc2F5IHN1Y2ggYSBzZXJ2ZXIgY291bGQgaGF2ZSBhIG1vcmUgY29uc3RyYWluZWQgcGFy c2VyIHRoYXQgZmFpbGVkIGFueQ0KIG5vbi13cyBjb21wbGlhbnQgaGFuZHNoYWtlIGV2ZW4gaWYg aXQgd2VyZSB2YWxpZCBoMS4gTW9zdGx5IEkgdGhpbmsgaXQgYmVjb21lcyBhbiBpbnNhbmVseSB1 Z2x5IHdoYXQgdG8gZG8gd2Vic29ja2V0IHBhcmFtZXRlciBleGNoYW5nZS48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJIHRoaW5rIG9mIG9yaWdpbiBpbmZvIChzY2hlbWUgYW5kIGF1dGhvcml0eSkgbW9y ZSBhcyBrZXlzIHRvIHJvdXRlIHRoZSBDT05ORUNUIHJlcXVlc3QuLiBpdCdzIDpwcm90b2NvbCB0 aGF0IGRlZmluZXMgd2hhdCB0byBkbyBpbiB0aGUgdHVubmVsLiBJIGFkbWl0IEkgZGlkIGNvbnNp ZGVyIGNhbGxpbmcgaXQgOmFscG4gKHdoaWNoIGhhcyBhIHNpbWlsYXIga2luZCBvZiBwcm9wZXJ0 eS4uIGl0cyBhIHJvdXRlIG9mIHNvcnRzIGJ1dCBpdCBkb2Vzbid0DQogYmVhciB0aGUgU0VUVElO R1Mgb3IgbWFnaWMgb2YgaDIpPGJyPg0KPGJyPg0KTWUgc3R1cGlkLiBNZSBhc2tpbmcsIHdoeSBu b3QgOnVwZ3JhZGU/PGJyPg0KPGJyPg0KaHQ7ZHIgKGhhdmUgdGltZSwgZG8gcmVhZCk8YnI+DQo8 YnI+DQpBcyBwcm9wb3NlZCwgdGhlIENPTk5ORUNUIHNlZW1zIHRvIHNheTogbGV0J3MgdGFsayBI VFRQLzEuMSBvbiB0aGlzIHN0cmVhbSBmcm9tIG5vdyBvbiwgYWZhaWN0Ljxicj4NCjxicj4NCkZy b20gYSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gcG92IHRoYXQgb3BlbnMgYSBsYXJnZXIgY2FuIG9m IHdvcm1zLiBJdCB3b3VsZCBtZWFuIHdhcm1pbmcgdXAgdGhlIEhUVFAvMS4xIGVuZ2luZSBmb3Ig dGhlIERBVEEgb24gdGhpcyBzdHJlYW0uIFRoYXQgbmVlZHMgc29tZSBleHRyYSBjYXJlIHNvIHRo YXQgaXQgZG9lcyBvbmx5IHNhZmUgdGhpbmdzIGluc2lkZSBhIGgyIHN0cmVhbS4gT24gZmlyc3Qg Z2xhbmNlLCBpdCBzZWVtcyB0byBiZSBlYXNpZXINCiBhbmQgc2FmZXIgdG8gZG8gdGhlIHN0cmVh bSA6dXBncmFkZSBpbnNpZGUgdGhlIGgyIHByb3RvY29sIGhhbmRsaW5nIGl0c2VsZi48YnI+DQo8 YnI+DQpKdXN0IG15IGluaXRpYWwgZ3V0IHJlYWN0aW9uLi4uPGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi1TdGVmYW48L3NwYW4+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsgWW91IGhhdmUga2luZCBvZiBs ZXQgdGhlIGNhdCBvdXQgb2YgdGhlIGJhZyBhdCBqdXN0IGRvaW5nIGFuIGgxIGNvbm5lY3QuIFRo YXQncyBhY3R1YWxseSBwb3NzaWJsZSB3aXRoIHRoZSBkcmFmdCAob3IgYXQgbGVhc3QgZW52aXNp b25lZCkgYXMgSSBkZWZpbmVkIDpwcm90b2NvbCBzZXBhcmF0ZSBmcm9tIHRoZSB3ZWJzb2NrZXQg c3BlY2lmaWMgc3R1ZmYuLi4gYnV0IEkga2luZGEgaG9wZSB0byBuZXZlciBzcGVhayBvZiBpdCBh Z2FpbiA6KTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgYSB0b3VnaCBvbmUgLSBpdHMgZGVm aW5pdGVseSBnb2luZyBmb3Igc2ltcGxpY2l0eSBhcyBpdHMgbWFpbiBnb2FsLi4gdGhhdCBtZWFu cyBpZ25vcmluZyBtYW55IHBsYWNlcyB0aGF0IGNhbiBiZSBpbXByb3ZlZC4gVGhhdCdzIGEgY2hv aWNlIGJhc2VkIG9uPGJyPg0KJmd0OyZuYnNwOyBhXSB0aGUgaGlzdG9yeSBvZiBvdGhlciBlZmZv cnRzIHNlZW0gdG8gc3VnZ2VzdCB0aGVyZSBpcyBubyBzdG9tYWNoIGZvciBjb21wbGV4aXR5L3Jp c2sgaGVyZTxicj4NCiZndDsmbmJzcDsgYl0gd2UgaGVhciBhYm91dCB0aGlzIHByb2JsZW0gZW5v dWdoIHRoYXQgSSB0aGluayBpdHMgd29ydGggc2VlaW5nIGlmIHRoaXMgY2FuIGJlIG0gYWRlIGEg Y29uc2Vuc3VzIG12cDxicj4NCiZndDsmbmJzcDsgY10gbXkgYmVsaWVmIHRoYXQgd2Vic29ja2V0 cyBpcyBhIHRyYW5zaXRpb25hbCB0ZWNobm9sb2d5IC0gaXQgd2lsbCBiZSBhcm91bmQgZm9yIHll YXJzIGJ1dCBzb21lIGtpbmQgb2YgbmF0aXZlIGh0dHAgd2lsbCBzdXBwbGFudCBpdC48YnI+DQom Z3Q7PGJyPg0KJmd0OyB5bW12IChtb3JlIHRoYW4gdXN1YWwgb24gdGhpcyBvbmUhKTxicj4NCiZn dDs8YnI+DQomZ3Q7IC1QPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgR2l2ZW4gdGhhdCB5b3XigJlyZSBkb2luZyB0aGUgZnVsbCBVcGdyYWRlLXRvLVdl YlNvY2tldHMgZGFuY2UgaW5zaWRlIHRoZSB0dW5uZWxlZCBjb25uZWN0aW9uLCB3aHkgZG9u4oCZ dCB5b3UganVzdCBzYXkgdGhhdCB5b3XigJlyZSBDT05ORUNUaW5nIHRvIGFuIEhUVFAvMS4xIHR1 bm5lbD8mbmJzcDsgVGhhdOKAmXMgdGhlbiB0cmVhdGVkIGFzIEhUVFAvMS4xIG92ZXIgVENQLCB3 aGljaCBpcyBmdWxseSBhbGxvd2VkIHRvIGRvIFVwZ3JhZGUgaXRzZWxmLiZuYnNwOyBJZiB5b3Xi gJlyZQ0KIHN1cmUgdGhhdOKAmXMgdGhlIHBhdGggeW91IHdhbnQsIHRoZW4gc2ltcGx5IHNheSBp biB0aGUgSFRUUC8yIGxheWVyIHRoYXQgeW914oCZcmUgZG9pbmcgSFRUUC8xLjEgaW5zaWRlIHRo ZSBzdHJlYW0uJm5ic3A7IEluY2lkZW50YWxseSwgdGhhdCBtaWdodCBiZSBhIG5pY2UgYWx0ZXJu YXRpdmUgZm9yIGRlYWxpbmcgd2l0aCBIVFRQXzFfMV9SRVFVSVJFRCByZXNwb25zZXMsIHRvbyE8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb206IFBhdHJpY2sgTWNN YW51cyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbSI+cG1jbWFu dXNAbW96aWxsYS5jb208L2E+XTxicj4NCiZndDsgU2VudDogTW9uZGF5LCBPY3RvYmVyIDE2LCAy MDE3IDU6MTYgQU08YnI+DQomZ3Q7IFRvOiBBbmR5IEdyZWVuICZsdDs8YSBocmVmPSJtYWlsdG86 YW5keUB3YXJtY2F0LmNvbSI+YW5keUB3YXJtY2F0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzog TWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbSI+cG1jbWFudXNAbW96aWxsYS5j b208L2E+Jmd0OzsgaHliaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh5YmlAaWV0Zi5vcmciPmh5YmlA aWV0Zi5vcmc8L2E+Jmd0OzsgQ29yeSBCZW5maWVsZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcnlA bHVrYXNhLmNvLnVrIj5jb3J5QGx1a2FzYS5jby51azwvYT4mZ3Q7Ow0KIFBhdHJpY2sgTWNNYW51 cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jbWFudXNAZHVja3NvbmcuY29tIj5tY21hbnVzQGR1Y2tz b25nLmNvbTwvYT4mZ3Q7OyBIVFRQIFdvcmtpbmcgR3JvdXAgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZXRmLWh0dHAtd2dAdzMub3JnIj5pZXRmLWh0dHAtd2dAdzMub3JnPC9hPiZndDs8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbaHliaV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t Y21hbnVzLWh0dHBiaXMtaDItd2Vic29ja2V0cy0wMC50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBPbiBNb24sIE9jdCAxNiwgMjAxNyBhdCAxMjo0NCBBTSwgQW5keSBHcmVlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFuZHlAd2FybWNhdC5jb20iPmFuZHlAd2FybWNhdC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgWW91IGNhbiBwcm9iYWJseSBwaXBlbGlu ZSB0aGUgQ09OTkVDVCAmIzQzOyB3cyBoYW5kc2hha2UgdGhvdWdoLCBQYXRyaWNrIHNob3dzIHRo ZW0gc2VxdWVudGlhbGx5IGFuZCBJIGRpZG4ndCB0aGluayBhYm91dCBpdCBteXNlbGYuPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyByaWdodC4gVGhlIGV4YW1wbGUgaXMg anVzdCBmb3IgY2xhcml0eSBhbmQgY2Fubm90IHNob3cgYWxsIGV4cHJlc3Npb25zIG9mIGgyIGZs b3dzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ09OTkVDVCAmIzQz OyBEQVRBIGJlZm9yZSB0aGUgcmVzcG9uc2UgaGVhZGVycyBpcyBwcmV0dHkgbXVjaCB0aGUgaDIg YW5hbG9nIG9mIFRDUCBGYXN0IE9wZW4uIFRoZSBkZXZpbCBpcyBpbiB0aGUgZGV0YWlscy4uIFRo YXQncyBhIGdlbmVyYWwgQ09OTkVDVCAmIzQzOyBEQVRBIGlzc3VlIG5vdCBsaW1pdGVkIHRvIHRo ZSBwcm90b2NvbCB1cGdyYWRlIGRlc2NyaWJlZCBoZXJlIHNvIEkgZG9uJ3QgdGhpbmsgaXRzIHdv cnRoIGRpc2N1c3Npb24gaW4gYSB3ZWJzb2NrZXRzDQogcmZjLjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGluayB0aGUgcGF0aCB0byBzdWNjZXNzIGhlcmUgaGlu Z2VzIG9uIGEgdmVyeSB0aWdodCBzY29waW5nIG9mIHdvcmsgYW5kIHRoZXJlZm9yZSBvcHRpbWl6 aW5nIGhhbmRzaGFrZSBsYXRlbmN5IGlzIGEgbm9uLWdvYWwgb2YgdGhpcyBlZmZvcnQuPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFN0 aWxsIG9ubHkgdHdvIHJvdW5kIHRyaXBzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAtIFNFVFRJTkdTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIFNFVFRJTkdTPGJyPg0KJmd0OyZu YnNwOyAtIEdFVCAvaW5kZXguaHRtbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIDIwMCBIRUFERVJTICYjNDM7 IERBVEE8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAtIDptZXRob2QgQ09OTkVDVDxicj4NCiZn dDsmbmJzcDsgLSBEQVRBIHdzIGhhbmRzaGFrZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstIDIwMCBI RUFERVJTPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gREFUQSB3cyBoYW5kc2hha2UgZmluYWw8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7LSBEQVRBLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgLSBE QVRBIC4uLiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0g REFUQS4uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdpdGggdGhlIHBhcnQgb2YgdGhlIHBpcGVsaW5p bmcgdGhhdCBpcyBsZWdhbCBmb3Igd3MsIHR3byByb3VuZCB0cmlwcyBiZWZvcmUgdGhlIGNsaWVu dCBjYW4gc3RhcnQgdG8gc2VuZCBkYXRhIGFuZCAxLjUgYmVmb3JlIHRoZSBzZXJ2ZXIgY2FuIHNl bmQgZGF0YS4uLiBpZiBpdCdzIHRydWUgdGhlbiB5b3UncmUgcmlnaHQgaXQncyBub3Qgc28gYmFk Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdlcmUgeW91IGNvbmNlcm5lZCB0aGF0IHRoZSBjbGllbnQg bmVlZHMgdG8gbGVhcm4gdGhhdCB0aGUgc2VydmVyPGJyPg0KJmd0OyBzdXBwb3J0cyB3ZWJzb2Nr ZXRzIGFuZCBub3QganVzdCA6cHJvdG9jb2w/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IE5vIEkganVzdCBmb2xsb3dlZCBQYXRyaWNrJ3Mgc2VxdWVuY2luZzsgaGUgc2hvd3MgdGhlbSBz ZXJpYWxpemVkLiZuYnNwOyBCdXQgeW91J3JlIHJpZ2h0IGF0IGxlYXN0IHRoZSBDT05ORUNUICYj NDM7IHdzIGhhbmRzaGFrZSBjYW4gcHJvYmFibHkgYmUgcGlwZWxpbmVkLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoYXQncyBhbHNvIGdvaW5nIHRvIGJlIGEgdmFyaWF0aW9uIGZyb20gbm9ybWFsIGgy IEhFQURFUlMgZmxvdyBpZiBJIHVuZGVyc3Rvb2QgaXQsIG9uIG9uZSBzdHJlYW0gdGhlcmUgd2ls bCBiZSBFTkRfSEVBREVScyBjb21pbmcgdHdpY2UgKGZvciB0aGUgQ09OTkVDVCBhbmQgdGhlIHdz IGhhbmRzaGFrZSBzZXBhcmF0ZWx5KTxicj4NCiZndDs8YnI+DQomZ3Q7IEFueXdheSB5b3UgYXJl IHJpZ2h0LCBpdCBtYWtlcyBhbnkgZGlmZmVyZW5jZSB3aXRoIFBVU0hfUFJPTUlTRSBwcm9iYWJs eSBub3Qgd29ydGggdGhlIGVmZm9ydC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtQW5keTxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB01415F7DABA1F6804AFD2669874C0MWHPR21MB0141namp_-- From nobody Tue Oct 17 11:19:45 2017 Return-Path: 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 EA8C6133070 for ; Tue, 17 Oct 2017 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YgvxPF-GUK82 for ; Tue, 17 Oct 2017 11:19:42 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC63126B6E for ; Tue, 17 Oct 2017 11:19:41 -0700 (PDT) Date: Wed, 18 Oct 2017 02:19:00 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Patrick McManus , Stefan Eissing CC: Mike Bishop , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group From: Andy Green Message-ID: Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:19:44 -0000 On October 17, 2017 10:34:16 PM GMT+08:00, Patrick McManus wrote: >Clearly substituting the h1 exchange out in favor of a new websockets >specific exchange that contained sub-protocol and version tokens would >look >better on paper=2E=2E=2E I actually thought diverging from 6455 would mak= e >people >LESS likely to implement=2E Maybe I'm wrong=2E > >So let's poll - please speak up if you have a ws impl (either client or >server): > >If the spec added a new websockets specific parameter negotiation and >removed the H1 syntax it would make me > a] MORE likely to implement > b] LESS likely to implement > c] wouldn't change my behavior but I like it more >d] wouldn't change my behavior but it would be more painful (or like it >less) > e] really don't care at all=2E c) =2E=2E=2E as discussed before only three persistant things come from th= e ws dance, agreement on both sides the stream is in an upgraded state, and= the server telling which protocol and any extensions + extension options a= pply=2E For the case where the peer is actually h1 ws hitching a ride on h2, the e= xtra RFC6455-only h1 header bits like Sec key hashes can be synthesized at = the boundary where the h1 stuff interfaces to the h2 stream, since they don= 't feature in the state after upgrade establishment and an h2 server doesn'= t need to see them at all=2E For the case the peer is natively h2 - surely it will become the common ca= se when this arrives in today's h2-preferring web browsers - doing a simple= r upgrade in native h2 is easier to implement, just don't do any of the old= Sec-key stuff at all=2E -Andy >On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing < >stefan=2Eeissing@greenbytes=2Ede> wrote: > >> >> >> > Am 16=2E10=2E2017 um 23:31 schrieb Patrick McManus >: >> > >> > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop < >> Michael=2EBishop@microsoft=2Ecom> wrote: >> [=2E=2E=2E] >> > >> > I hear what you're saying=2E=2E but I think you're going a touch too >far=2E >> websocket means 6455 which has all that h1 stuff as part of its >> configuration=2E=2E I think it would be totally fair to say such a serv= er >could >> have a more constrained parser that failed any non-ws compliant >handshake >> even if it were valid h1=2E Mostly I think it becomes an insanely ugly >what >> to do websocket parameter exchange=2E >> > >> > I think of origin info (scheme and authority) more as keys to route >the >> CONNECT request=2E=2E it's :protocol that defines what to do in the >tunnel=2E I >> admit I did consider calling it :alpn (which has a similar kind of >> property=2E=2E its a route of sorts but it doesn't bear the SETTINGS or >magic >> of h2) >> >> Me stupid=2E Me asking, why not :upgrade? >> >> ht;dr (have time, do read) >> >> As proposed, the CONNNECT seems to say: let's talk HTTP/1=2E1 on this >stream >> from now on, afaict=2E >> >> From a server implementation pov that opens a larger can of worms=2E It >> would mean warming up the HTTP/1=2E1 engine for the DATA on this >stream=2E That >> needs some extra care so that it does only safe things inside a h2 >stream=2E >> On first glance, it seems to be easier and safer to do the stream >:upgrade >> inside the h2 protocol handling itself=2E >> >> Just my initial gut reaction=2E=2E=2E >> >> -Stefan >> >> > You have kind of let the cat out of the bag at just doing an h1 >connect=2E >> That's actually possible with the draft (or at least envisioned) as I >> defined :protocol separate from the websocket specific stuff=2E=2E=2E b= ut I >kinda >> hope to never speak of it again :) >> > >> > This is a tough one - its definitely going for simplicity as its >main >> goal=2E=2E that means ignoring many places that can be improved=2E That= 's a >> choice based on >> > a] the history of other efforts seem to suggest there is no >stomach for >> complexity/risk here >> > b] we hear about this problem enough that I think its worth seeing >if >> this can be m ade a consensus mvp >> > c] my belief that websockets is a transitional technology - it >will be >> around for years but some kind of native http will supplant it=2E >> > >> > ymmv (more than usual on this one!) >> > >> > -P >> > >> > >> > >> > >> > Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance = inside >the >> tunneled connection, why don=E2=80=99t you just say that you=E2=80=99re= CONNECTing to >an >> HTTP/1=2E1 tunnel? That=E2=80=99s then treated as HTTP/1=2E1 over TCP,= which is >fully >> allowed to do Upgrade itself=2E If you=E2=80=99re sure that=E2=80=99s = the path you >want, >> then simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1=2E= 1 inside >the >> stream=2E Incidentally, that might be a nice alternative for dealing >with >> HTTP_1_1_REQUIRED responses, too! >> > >> > >> > >> > From: Patrick McManus [mailto:pmcmanus@mozilla=2Ecom] >> > Sent: Monday, October 16, 2017 5:16 AM >> > To: Andy Green >> > Cc: Martin Thomson ; Patrick McManus < >> pmcmanus@mozilla=2Ecom>; hybi ; Cory Benfield < >> cory@lukasa=2Eco=2Euk>; Patrick McManus ; HTTP >Working >> Group >> > Subject: Re: [hybi] New Version Notification for >> draft-mcmanus-httpbis-h2-websockets-00=2Etxt >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green >wrote: >> > >> > >> > You can probably pipeline the CONNECT + ws handshake though, >Patrick >> shows them sequentially and I didn't think about it myself=2E >> > >> > >> > >> > right=2E The example is just for clarity and cannot show all >expressions >> of h2 flows=2E >> > >> > >> > >> > CONNECT + DATA before the response headers is pretty much the h2 >analog >> of TCP Fast Open=2E The devil is in the details=2E=2E That's a general >CONNECT + >> DATA issue not limited to the protocol upgrade described here so I >don't >> think its worth discussion in a websockets rfc=2E >> > >> > >> > >> > I think the path to success here hinges on a very tight scoping of >work >> and therefore optimizing handshake latency is a non-goal of this >effort=2E >> > >> > >> > >> > >> > >> > Still only two round trips=2E >> > >> > >> > - SETTINGS - SETTINGS >> > - GET /index=2Ehtml >> > - 200 HEADERS + DATA >> > >> > - :method CONNECT >> > - DATA ws handshake >> > - 200 HEADERS >> > - DATA ws handshake final >> > - DATA=2E=2E=2E >> > >> > - DATA =2E=2E=2E - DATA=2E=2E=2E >> > >> > With the part of the pipelining that is legal for ws, two round >trips >> before the client can start to send data and 1=2E5 before the server >can send >> data=2E=2E=2E if it's true then you're right it's not so bad=2E >> > >> > Were you concerned that the client needs to learn that the server >> > supports websockets and not just :protocol? >> > >> > >> > No I just followed Patrick's sequencing; he shows them serialized=2E= =20 >But >> you're right at least the CONNECT + ws handshake can probably be >pipelined=2E >> > >> > That's also going to be a variation from normal h2 HEADERS flow if >I >> understood it, on one stream there will be END_HEADERs coming twice >(for >> the CONNECT and the ws handshake separately) >> > >> > Anyway you are right, it makes any difference with PUSH_PROMISE >probably >> not worth the effort=2E >> > >> > -Andy >> > >> > >> > >> > >> >> From nobody Tue Oct 17 11:33:45 2017 Return-Path: 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 A68D7133080 for ; Tue, 17 Oct 2017 11:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no 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 7cB8ELsgE8F4 for ; Tue, 17 Oct 2017 11:33:33 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD739133070 for ; Tue, 17 Oct 2017 11:33:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 7ACBD4DC6B; Tue, 17 Oct 2017 21:33:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id twughm8oBG8T; Tue, 17 Oct 2017 21:33:27 +0300 (EEST) Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPS id D758FC4; Tue, 17 Oct 2017 21:33:21 +0300 (EEST) To: Patrick McManus , HTTP Working Group Date: Tue, 17 Oct 2017 21:33:20 +0300 (EEST) Sender: hurtta@hurtta09lk.keh.iki.fi From: Kari Hurtta CC: Kari Hurtta , hybi X-Mailer: ELM [version ME+ 2.5 PLalpha46+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171017183329.7ACBD4DC6B@welho-filter3.welho.com> Archived-At: Subject: [hybi] draft-mcmanus-httpbis-h2-websockets X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:33:35 -0000 https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00#section-4.2 " [[ From Client ]] [[ From Server ]] " " SETTINGS " ENABLE_CONNECT_PROTOCOL = 1 " " HEADERS + END_HEADERS " :method = CONNECT " :protocol = websocket " :scheme = wss " :path = /chat " :authority = server.example.com:443 " " HEADERS + END_HEADERS " :status = 200 " " DATA " GET /chat HTTP/1.1 " Host: server.example.com " Upgrade: websocket " Connection: Upgrade " Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== " Origin: http://example.com " Sec-WebSocket-Protocol: chat, superchat " Sec-WebSocket-Version: 13 " " DATA " HTTP/1.1 101 Plead The Fifth " Upgrade: websocket " Connection: Upgrade " Sec-WebSocket-Accept: " s3pPLMBiTxaQ9kYGzzhZRbK+xOo= " Sec-WebSocket-Protocol: chat " " DATA " WebSocket Data " " DATA + END_STREAM " WebSocket Data " " DATA + END_STREAM " WebSocket Data I'm wondering 1) why this is is not " SETTINGS " ENABLE_CONNECT_PROTOCOL = 1 " " HEADERS + END_HEADERS " :method = CONNECT " :protocol = websocket " :scheme = wss " :path = /chat " :authority = server.example.com:443 " sec-webSocket-key = dGhlIHNhbXBsZSBub25jZQ== " origin = http://example.com " sec-websocket-protocol = chat, superchat " sec-websocket-version = 13 " " HEADERS + END_HEADERS " :status = 200 " sec-websocket-accept = s3pPLMBiTxaQ9kYGzzhZRbK+xOo= " sec-websocket-protocol = chat " " DATA " WebSocket Data " " " DATA + END_STREAM " WebSocket Data 2) What happens if this is " [[ From Client ]] [[ From Server ]] " " SETTINGS " ENABLE_CONNECT_PROTOCOL = 1 " " HEADERS + END_HEADERS " :method = CONNECT " :protocol = websocket " :scheme = wss " :path = /chat " :authority = server.example.com:443 " " HEADERS + END_HEADERS " :status = 200 " " DATA " GET /admin HTTP/1.1 " Host: server.example.org " Upgrade: websocket " Connection: Upgrade " Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== " Origin: http://example.org " Sec-WebSocket-Protocol: chat, superchat " Sec-WebSocket-Version: 13 That is: "outer" (h2) and "inner" (websocket) handshake gives different data. / Kari Hurtta From nobody Wed Oct 18 11:00:04 2017 Return-Path: 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 244DB132C2A for ; Wed, 18 Oct 2017 11:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=microsoft.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 1JroP7DVK4dE for ; Wed, 18 Oct 2017 10:59:58 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0105.outbound.protection.outlook.com [104.47.36.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62A613300C for ; Wed, 18 Oct 2017 10:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JDYtFh0fvch8KSQ5FKZhurXq6d0rdKgV1z3cdnDvtsc=; b=iSXfJl4vbe5xPVNGzeDzcbbegUNSvQVKeRGAQEi1zMFce9M598hpJNQ+ptJ+cRGDx4BA75oMuzjGgDM5UlIVNDrRlV2t2v3CB4aWa85jLqhsplkBKtTOi8qLHsAnuQQuBqIrLibdgVbkEttmawHx5J3uaxmtRANO20RMK+wBzp0= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0175.namprd21.prod.outlook.com (10.173.52.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Wed, 18 Oct 2017 17:59:54 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0178.002; Wed, 18 Oct 2017 17:59:54 +0000 From: Mike Bishop To: Patrick McManus , Stefan Eissing CC: Andy Green , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group Thread-Topic: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt Thread-Index: AQHTRnkXSa3fJMYEE0KGC67TZNNyA6LmtAUggABLXYCAAMADgIAAXa0AgAAcXDCAAa0pEA== Date: Wed, 18 Oct 2017 17:59:54 +0000 Message-ID: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:c::28b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0175; 6:sL26QgU9fwGm0Narta1tsafmyvxLgSflWjx1kxIGwAdnDDmGYUyrjxJBiqL1yxmYKBfGPR7+8tyyZN+kESr+fGI+TOXFq7VynX0Ha8t7p8KtwzI0HbBWVZdKp/If2/cGqJo7CsWJlwmKnNG3EQuUzMyVu3K8aR+j4I4farOsM2vsS0uLdJkfG6D3dBpIJ9mFg/CpN7ypSTAQgTeN0j/t6Evmqq3pqT5P1vu9pMwxPz6XDks6Dcd6KsDMF3v4seUew0Aw/oYqwWExs94vmyH2pnCv4Ts6uXUS5McQ3+nP3v+b1oJ44YwvdNb4I29+X3uUAxTllSMJiWgQOsNDmjaUBflr4Uqo68LPkp0yMMa2CeE=; 5:PKNoanSn/yYsGJkX7qWktbtZNKrwlomz7zOqcQObcZFGsMOlcPBNGKZbr74Y7G6C20TvqZBx05XdpbTslxQYVxL31HzRSu6tRJbpBTPP/WO9u1HQdV6KZaExQ4+C7N9/AnYJ97rnBb3bt5ym7KnKl783liqzm3dAgge6m0xC7nw=; 24:qTNxYLisUe34Vi1FBFIA7SClTK4fefCq0sQX4wvUTTp+EtpARpE9mx8VEz2L9aEuprr/lRKAklgZymRXZtjhirbhUwWUnxFUazx/mY4nmEA=; 7:nPk97E/3S9BSEEhaGaEjieIm3kIW6d54dMxnxIGc/C07nvTvvEC/z5KXSOTyyKysMhbyE+Ct+/JXqsMXdm6a5Q12wBWmpPAUWmBY4QxWmqSMqLgKS1xO/+/Li66ZIPQZdALSS4eT+HFO8gYok2Oh+FXDRIdSsmTGpeoauPBUa3Za/Jo8joOoUfEZFlUMgUS02iivaWhH+5J+MGrynXgTsQkOABcMiaK5divME3g6HJ1Leym1l6uvBQjdvbnmfRbu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 86b014de-a12b-4cb0-05b2-08d5165209c0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603224)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0175; x-ms-traffictypediagnostic: MWHPR21MB0175: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(100405760836317)(21748063052155)(21532816269658)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0175; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0175; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(47760400005)(24454002)(199003)(189002)(377454003)(77096006)(50986999)(76176999)(236005)(9686003)(74316002)(54896002)(478600001)(6436002)(54906003)(53936002)(55016002)(99286003)(2950100002)(7110500001)(7696004)(189998001)(7736002)(53546010)(14454004)(110136005)(8990500004)(10290500003)(5660300001)(19609705001)(8936002)(54356999)(347745004)(3660700001)(6306002)(106356001)(72206003)(105586002)(8676002)(6506006)(3280700002)(790700001)(316002)(102836003)(6116002)(97736004)(229853002)(33656002)(25786009)(101416001)(93886005)(22452003)(81166006)(2900100001)(39060400002)(86612001)(6246003)(10710500007)(4326008)(81156014)(230783001)(15650500001)(2420400007)(10090500001)(2906002)(86362001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0175; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01415416D25047646965567B874D0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86b014de-a12b-4cb0-05b2-08d5165209c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 17:59:54.8621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0175 Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 18:00:02 -0000 --_000_MWHPR21MB01415416D25047646965567B874D0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGF2aW5nIGRpc2N1c3NlZCB3aXRoIG91ciBkZXYgbGVhZCwgSSB0aGluayB0aGVyZeKAmXMgb25l IG90aGVyIGJhcnJpZXIgaGVyZTogIFN0YXRlIG1hY2hpbmUuICBXZWJTb2NrZXQgcmVxdWVzdHMg dGhhdCBzdXBwb3J0IFVwZ3JhZGUgaGF2ZSB0byBnbyB0byB0aGUgcmVzb3VyY2UgdG8gZGVjaWRl IHdoZXRoZXIgdG8gYWNjZXB0IHRoZW0sIGFuZCBoYXZpbmcgdHdvIOKAnGVuY2Fwc3VsYXRlZOKA nSByZXF1ZXN0cyBpcyBjaGFsbGVuZ2luZy4gIExpa2V3aXNlLCB0aGUgY2xpZW50IHNlbmRzIHR3 byByZXF1ZXN0cywgd2hpY2ggY29udG9ydHMgdGhlIGV4cG9zZWQgc3RhdGUgbWFjaGluZSBvbiB0 aGF0IHNpZGUuICBXZSBjb3VsZCBsaWUgYW5kIHVzZSB0aGUgc3RhdGVzIHRoYXQgZXhpc3QgZm9y IGNvbm5lY3RpbmcgdmlhIGEgcHJveHksIGJ1dCBpZiB0aGUgY2xpZW50IGlzbuKAmXQgZXhwZWN0 aW5nIHRvIHVzZSBhIHByb3h5IHRoYXTigJlzIGVxdWFsbHkgcHJvYmxlbWF0aWMuDQoNCkkgdGhp bmsgd2XigJlyZSBhbWVuYWJsZSB0byBkZWZpbmluZyBhIHdheSB0byBkZWZpbmUgdXBncmFkZS1v Zi1zdHJlYW0sIGJ1dCB0aGUgZG91YmxlLXVwZ3JhZGUgbW9kZWwgaXMgY2hhbGxlbmdpbmcuDQoN CkFsc28sIGhlIHBvaW50ZWQgb3V0IHRoYXQgbGVnYWN5IFdlYlNvY2tldHMgaGFkIHRoZSB1c2Vm dWwgcHJvcGVydHkgdGhhdCBhbiB1bnN1cHBvcnRpbmcgc2VydmVyIHdvdWxkIHNpbXBseSBoYW5k bGUgdGhlIHZhbmlsbGEgR0VULCByYXRoZXIgdGhhbiBmYWlsaW5nIGVudGlyZWx5LiAgVGhlIHNl cnZlciBzZXR0aW5nIHBhcnRpYWxseSBtaXRpZ2F0ZXMgdGhhdCwgYnV0IHlvdSBzdGlsbCBkb27i gJl0IGtub3cgd2hpY2ggcHJvdG9jb2xzIHRoZSBzZXJ2ZXIgaXMgd2lsbGluZyB0byBjb25zaWRl ci4NCg0KRnJvbTogTWlrZSBCaXNob3ANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTcsIDIwMTcg OTozNCBBTQ0KVG86ICdQYXRyaWNrIE1jTWFudXMnIDxwbWNtYW51c0Btb3ppbGxhLmNvbT47IFN0 ZWZhbiBFaXNzaW5nIDxzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPg0KQ2M6IEFuZHkgR3Jl ZW4gPGFuZHlAd2FybWNhdC5jb20+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPjsgaHliaSA8aHliaUBpZXRmLm9yZz47IENvcnkgQmVuZmllbGQgPGNvcnlAbHVrYXNh LmNvLnVrPjsgTWNNYW51cyBQYXRyaWNrIDxtY21hbnVzQGR1Y2tzb25nLmNvbT47IEhUVFAgV29y a2luZyBHcm91cCA8aWV0Zi1odHRwLXdnQHczLm9yZz4NClN1YmplY3Q6IFJFOiBbaHliaV0gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tY21hbnVzLWh0dHBiaXMtaDItd2Vic29j a2V0cy0wMC50eHQNCg0KVGhpcyBpcyBzb21ld2hhdCBjb25qZWN0dXJlLCBzaW5jZSBJIGhhdmVu 4oCZdCBnb25lIG92ZXIgaXQgd2l0aCBvdXIgZGV2IHRlYW0sIGJ1dCBJIHRoaW5rIGl0IHBsYXlz IG91dCB0byAoYykuICBXZeKAmXZlIGhhZCBlbm91Z2ggcGVvcGxlIGFzayBmb3IgV2ViU29ja2V0 IHN1cHBvcnQsIGl0IHdpbGwgZXZlbnR1YWxseSBoYXBwZW4gaWYgdGhlcmXigJlzIGFuIGludGVy b3BlcmFibGUgd2F5IHRvIGRvIGl0LiAgSUlSQywgVXBncmFkZSBpcyBwbHVnZ2FibGUuIFdoZW4g YSBwcm90b2NvbCB1cGdyYWRlcyB0byB3ZWJzb2NrZXQsIHdlIGNoZWNrIGlmIHRoZXJl4oCZcyBh IGhhbmRsZXIgZm9yIHRoYXQgcHJvdG9jb2wuICBJZiBzbywgd2UgcmV0dXJuIDEwMSBhbmQgZ2l2 ZSBjb250cm9sIG9mIHRoZSBUQ1AgY29ubmVjdGlvbiB0byB0aGF0IGhhbmRsZXI7IHRoZSBIVFRQ IGxheWVyIGJlY29tZXMgcGFzc3Rocm91Z2guDQoNCklmIHdlIGhhdmUgdG8gc3VwcG9ydCBwdWxs aW5nIGluIEhUVFAvMS4xIHBhcnNpbmcgdG8gdGhhdCBzdHJlYW0gc2ltcGx5IHRvIGRvIGFuIFVw Z3JhZGUsIHRoYXTigJlzIGFuIGFkZGl0aW9uYWwgc2NlbmFyaW8gd2UgaGF2ZSB0byBzdXBwb3J0 IGluLWxpbmUgZmlyc3QsIGFuZCBhbiBleHRyYSBsYXllciB0byBnbyBwYXNzdGhyb3VnaCBpbiB0 aGUgaG9wZWZ1bGx5LWNvbW1vbiBjYXNlLiAgSeKAmWQgcmF0aGVyIGJlIGFibGUgdG8gaGFuZCB0 aGUgc3RyZWFtIGRpcmVjdGx5IHRvIHRoZSBXZWJTb2NrZXQgbGlicmFyeSAob3duZWQgYnkgYSBk aWZmZXJlbnQgdGVhbSkgYW5kIGJlIGRvbmUsIGV2ZW4gaWYgaXQgbWVhbnMgdGhlcmXigJlzIGFu IEgyLXNwZWNpZmljIFVwZ3JhZGUgcGF0aC4gIChXaGljaCwgaXQgdHVybnMgb3V0LCB0aGVyZSBp cyBpbiB0aGlzIGRyYWZ0IGFscmVhZHkuKQ0KDQpXZSBjb3VsZCBzdGlsbCBkZWNpZGUgdG8gc3Vw cG9ydCBIMi3igJx1cGdyYWRl4oCdLXRvLUgxIGluIHRoZSBmdXR1cmUsIGJ1dCBpdCB3b3VsZCBi ZSBiZWNhdXNlIHRoYXTigJlzIGEgZmVhdHVyZSB3ZSBmb3VuZCB3ZSBuZWVkZWQgZm9yIHNvbWUg cmVhc29uLCBub3QgYmVjYXVzZSBpdCB3YXMgYW4gYW5ub3lpbmcgc3RlcHBpbmctc3RvbmUgdG8g c29tZXRoaW5nIHdlIGFjdHVhbGx5IHdhbnRlZC4gIChJbiBmYWN0LCBvdXIgbW9zdCBjb21tb24g cmVhc29uIHRvIGlzc3VlIEhUVFBfMV8xX1JFUVVJUkVEIGlzIGNsaWVudCBjZXJ0aWZpY2F0ZXMs IHdoaWNoIHRoaXMgd29u4oCZdCBoZWxwLikNCg0KRnJvbTogUGF0cmljayBNY01hbnVzIFttYWls dG86cG1jbWFudXNAbW96aWxsYS5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE3LCAyMDE3 IDc6MzQgQU0NClRvOiBTdGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5k ZTxtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4+DQpDYzogUGF0cmljayBNY01h bnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbTxtYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb20+Pjsg TWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu QmlzaG9wQG1pY3Jvc29mdC5jb20+PjsgQW5keSBHcmVlbiA8YW5keUB3YXJtY2F0LmNvbTxtYWls dG86YW5keUB3YXJtY2F0LmNvbT4+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PjsgaHliaSA8aHliaUBpZXRm Lm9yZzxtYWlsdG86aHliaUBpZXRmLm9yZz4+OyBDb3J5IEJlbmZpZWxkIDxjb3J5QGx1a2FzYS5j by51azxtYWlsdG86Y29yeUBsdWthc2EuY28udWs+PjsgTWNNYW51cyBQYXRyaWNrIDxtY21hbnVz QGR1Y2tzb25nLmNvbTxtYWlsdG86bWNtYW51c0BkdWNrc29uZy5jb20+PjsgSFRUUCBXb3JraW5n IEdyb3VwIDxpZXRmLWh0dHAtd2dAdzMub3JnPG1haWx0bzppZXRmLWh0dHAtd2dAdzMub3JnPj4N ClN1YmplY3Q6IFJlOiBbaHliaV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t Y21hbnVzLWh0dHBiaXMtaDItd2Vic29ja2V0cy0wMC50eHQNCg0KQ2xlYXJseSBzdWJzdGl0dXRp bmcgdGhlIGgxIGV4Y2hhbmdlIG91dCBpbiBmYXZvciBvZiBhIG5ldyB3ZWJzb2NrZXRzIHNwZWNp ZmljIGV4Y2hhbmdlIHRoYXQgY29udGFpbmVkIHN1Yi1wcm90b2NvbCBhbmQgdmVyc2lvbiB0b2tl bnMgd291bGQgbG9vayBiZXR0ZXIgb24gcGFwZXIuLi4gSSBhY3R1YWxseSB0aG91Z2h0IGRpdmVy Z2luZyBmcm9tIDY0NTUgd291bGQgbWFrZSBwZW9wbGUgTEVTUyBsaWtlbHkgdG8gaW1wbGVtZW50 LiBNYXliZSBJJ20gd3JvbmcuDQoNClNvIGxldCdzIHBvbGwgLSBwbGVhc2Ugc3BlYWsgdXAgaWYg eW91IGhhdmUgYSB3cyBpbXBsIChlaXRoZXIgY2xpZW50IG9yIHNlcnZlcik6DQoNCklmIHRoZSBz cGVjIGFkZGVkIGEgbmV3IHdlYnNvY2tldHMgc3BlY2lmaWMgcGFyYW1ldGVyIG5lZ290aWF0aW9u IGFuZCByZW1vdmVkIHRoZSBIMSBzeW50YXggaXQgd291bGQgbWFrZSBtZQ0KIGFdIE1PUkUgbGlr ZWx5IHRvIGltcGxlbWVudA0KIGJdIExFU1MgbGlrZWx5IHRvIGltcGxlbWVudA0KIGNdIHdvdWxk bid0IGNoYW5nZSBteSBiZWhhdmlvciBidXQgSSBsaWtlIGl0IG1vcmUNCiBkXSB3b3VsZG4ndCBj aGFuZ2UgbXkgYmVoYXZpb3IgYnV0IGl0IHdvdWxkIGJlIG1vcmUgcGFpbmZ1bCAob3IgbGlrZSBp dCBsZXNzKQ0KIGVdIHJlYWxseSBkb24ndCBjYXJlIGF0IGFsbC4NCg0KT24gVHVlLCBPY3QgMTcs IDIwMTcgYXQgNDo1OCBBTSwgU3RlZmFuIEVpc3NpbmcgPHN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0 ZXMuZGU8bWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU+PiB3cm90ZToNCg0KDQo+ IEFtIDE2LjEwLjIwMTcgdW0gMjM6MzEgc2NocmllYiBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVz QG1vemlsbGEuY29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbT4+Og0KPg0KPiBPbiBNb24s IE9jdCAxNiwgMjAxNyBhdCAxOjEzIFBNLCBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K Wy4uLl0NCj4NCj4gSSBoZWFyIHdoYXQgeW91J3JlIHNheWluZy4uIGJ1dCBJIHRoaW5rIHlvdSdy ZSBnb2luZyBhIHRvdWNoIHRvbyBmYXIuIHdlYnNvY2tldCBtZWFucyA2NDU1IHdoaWNoIGhhcyBh bGwgdGhhdCBoMSBzdHVmZiBhcyBwYXJ0IG9mIGl0cyBjb25maWd1cmF0aW9uLi4gSSB0aGluayBp dCB3b3VsZCBiZSB0b3RhbGx5IGZhaXIgdG8gc2F5IHN1Y2ggYSBzZXJ2ZXIgY291bGQgaGF2ZSBh IG1vcmUgY29uc3RyYWluZWQgcGFyc2VyIHRoYXQgZmFpbGVkIGFueSBub24td3MgY29tcGxpYW50 IGhhbmRzaGFrZSBldmVuIGlmIGl0IHdlcmUgdmFsaWQgaDEuIE1vc3RseSBJIHRoaW5rIGl0IGJl Y29tZXMgYW4gaW5zYW5lbHkgdWdseSB3aGF0IHRvIGRvIHdlYnNvY2tldCBwYXJhbWV0ZXIgZXhj aGFuZ2UuDQo+DQo+IEkgdGhpbmsgb2Ygb3JpZ2luIGluZm8gKHNjaGVtZSBhbmQgYXV0aG9yaXR5 KSBtb3JlIGFzIGtleXMgdG8gcm91dGUgdGhlIENPTk5FQ1QgcmVxdWVzdC4uIGl0J3MgOnByb3Rv Y29sIHRoYXQgZGVmaW5lcyB3aGF0IHRvIGRvIGluIHRoZSB0dW5uZWwuIEkgYWRtaXQgSSBkaWQg Y29uc2lkZXIgY2FsbGluZyBpdCA6YWxwbiAod2hpY2ggaGFzIGEgc2ltaWxhciBraW5kIG9mIHBy b3BlcnR5Li4gaXRzIGEgcm91dGUgb2Ygc29ydHMgYnV0IGl0IGRvZXNuJ3QgYmVhciB0aGUgU0VU VElOR1Mgb3IgbWFnaWMgb2YgaDIpDQoNCk1lIHN0dXBpZC4gTWUgYXNraW5nLCB3aHkgbm90IDp1 cGdyYWRlPw0KDQpodDtkciAoaGF2ZSB0aW1lLCBkbyByZWFkKQ0KDQpBcyBwcm9wb3NlZCwgdGhl IENPTk5ORUNUIHNlZW1zIHRvIHNheTogbGV0J3MgdGFsayBIVFRQLzEuMSBvbiB0aGlzIHN0cmVh bSBmcm9tIG5vdyBvbiwgYWZhaWN0Lg0KDQpGcm9tIGEgc2VydmVyIGltcGxlbWVudGF0aW9uIHBv diB0aGF0IG9wZW5zIGEgbGFyZ2VyIGNhbiBvZiB3b3Jtcy4gSXQgd291bGQgbWVhbiB3YXJtaW5n IHVwIHRoZSBIVFRQLzEuMSBlbmdpbmUgZm9yIHRoZSBEQVRBIG9uIHRoaXMgc3RyZWFtLiBUaGF0 IG5lZWRzIHNvbWUgZXh0cmEgY2FyZSBzbyB0aGF0IGl0IGRvZXMgb25seSBzYWZlIHRoaW5ncyBp bnNpZGUgYSBoMiBzdHJlYW0uIE9uIGZpcnN0IGdsYW5jZSwgaXQgc2VlbXMgdG8gYmUgZWFzaWVy IGFuZCBzYWZlciB0byBkbyB0aGUgc3RyZWFtIDp1cGdyYWRlIGluc2lkZSB0aGUgaDIgcHJvdG9j b2wgaGFuZGxpbmcgaXRzZWxmLg0KDQpKdXN0IG15IGluaXRpYWwgZ3V0IHJlYWN0aW9uLi4uDQoN Ci1TdGVmYW4NCg0KPiBZb3UgaGF2ZSBraW5kIG9mIGxldCB0aGUgY2F0IG91dCBvZiB0aGUgYmFn IGF0IGp1c3QgZG9pbmcgYW4gaDEgY29ubmVjdC4gVGhhdCdzIGFjdHVhbGx5IHBvc3NpYmxlIHdp dGggdGhlIGRyYWZ0IChvciBhdCBsZWFzdCBlbnZpc2lvbmVkKSBhcyBJIGRlZmluZWQgOnByb3Rv Y29sIHNlcGFyYXRlIGZyb20gdGhlIHdlYnNvY2tldCBzcGVjaWZpYyBzdHVmZi4uLiBidXQgSSBr aW5kYSBob3BlIHRvIG5ldmVyIHNwZWFrIG9mIGl0IGFnYWluIDopDQo+DQo+IFRoaXMgaXMgYSB0 b3VnaCBvbmUgLSBpdHMgZGVmaW5pdGVseSBnb2luZyBmb3Igc2ltcGxpY2l0eSBhcyBpdHMgbWFp biBnb2FsLi4gdGhhdCBtZWFucyBpZ25vcmluZyBtYW55IHBsYWNlcyB0aGF0IGNhbiBiZSBpbXBy b3ZlZC4gVGhhdCdzIGEgY2hvaWNlIGJhc2VkIG9uDQo+ICBhXSB0aGUgaGlzdG9yeSBvZiBvdGhl ciBlZmZvcnRzIHNlZW0gdG8gc3VnZ2VzdCB0aGVyZSBpcyBubyBzdG9tYWNoIGZvciBjb21wbGV4 aXR5L3Jpc2sgaGVyZQ0KPiAgYl0gd2UgaGVhciBhYm91dCB0aGlzIHByb2JsZW0gZW5vdWdoIHRo YXQgSSB0aGluayBpdHMgd29ydGggc2VlaW5nIGlmIHRoaXMgY2FuIGJlIG0gYWRlIGEgY29uc2Vu c3VzIG12cA0KPiAgY10gbXkgYmVsaWVmIHRoYXQgd2Vic29ja2V0cyBpcyBhIHRyYW5zaXRpb25h bCB0ZWNobm9sb2d5IC0gaXQgd2lsbCBiZSBhcm91bmQgZm9yIHllYXJzIGJ1dCBzb21lIGtpbmQg b2YgbmF0aXZlIGh0dHAgd2lsbCBzdXBwbGFudCBpdC4NCj4NCj4geW1tdiAobW9yZSB0aGFuIHVz dWFsIG9uIHRoaXMgb25lISkNCj4NCj4gLVANCj4NCj4NCj4NCj4NCj4gR2l2ZW4gdGhhdCB5b3Xi gJlyZSBkb2luZyB0aGUgZnVsbCBVcGdyYWRlLXRvLVdlYlNvY2tldHMgZGFuY2UgaW5zaWRlIHRo ZSB0dW5uZWxlZCBjb25uZWN0aW9uLCB3aHkgZG9u4oCZdCB5b3UganVzdCBzYXkgdGhhdCB5b3Xi gJlyZSBDT05ORUNUaW5nIHRvIGFuIEhUVFAvMS4xIHR1bm5lbD8gIFRoYXTigJlzIHRoZW4gdHJl YXRlZCBhcyBIVFRQLzEuMSBvdmVyIFRDUCwgd2hpY2ggaXMgZnVsbHkgYWxsb3dlZCB0byBkbyBV cGdyYWRlIGl0c2VsZi4gIElmIHlvdeKAmXJlIHN1cmUgdGhhdOKAmXMgdGhlIHBhdGggeW91IHdh bnQsIHRoZW4gc2ltcGx5IHNheSBpbiB0aGUgSFRUUC8yIGxheWVyIHRoYXQgeW914oCZcmUgZG9p bmcgSFRUUC8xLjEgaW5zaWRlIHRoZSBzdHJlYW0uICBJbmNpZGVudGFsbHksIHRoYXQgbWlnaHQg YmUgYSBuaWNlIGFsdGVybmF0aXZlIGZvciBkZWFsaW5nIHdpdGggSFRUUF8xXzFfUkVRVUlSRUQg cmVzcG9uc2VzLCB0b28hDQo+DQo+DQo+DQo+IEZyb206IFBhdHJpY2sgTWNNYW51cyBbbWFpbHRv OnBtY21hbnVzQG1vemlsbGEuY29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbT5dDQo+IFNl bnQ6IE1vbmRheSwgT2N0b2JlciAxNiwgMjAxNyA1OjE2IEFNDQo+IFRvOiBBbmR5IEdyZWVuIDxh bmR5QHdhcm1jYXQuY29tPG1haWx0bzphbmR5QHdhcm1jYXQuY29tPj4NCj4gQ2M6IE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPG1haWx0bzpw bWNtYW51c0Btb3ppbGxhLmNvbT4+OyBoeWJpIDxoeWJpQGlldGYub3JnPG1haWx0bzpoeWJpQGll dGYub3JnPj47IENvcnkgQmVuZmllbGQgPGNvcnlAbHVrYXNhLmNvLnVrPG1haWx0bzpjb3J5QGx1 a2FzYS5jby51az4+OyBQYXRyaWNrIE1jTWFudXMgPG1jbWFudXNAZHVja3NvbmcuY29tPG1haWx0 bzptY21hbnVzQGR1Y2tzb25nLmNvbT4+OyBIVFRQIFdvcmtpbmcgR3JvdXAgPGlldGYtaHR0cC13 Z0B3My5vcmc8bWFpbHRvOmlldGYtaHR0cC13Z0B3My5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogW2h5 YmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWNtYW51cy1odHRwYmlzLWgy LXdlYnNvY2tldHMtMDAudHh0DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IE9uIE1vbiwgT2N0IDE2 LCAyMDE3IGF0IDEyOjQ0IEFNLCBBbmR5IEdyZWVuIDxhbmR5QHdhcm1jYXQuY29tPG1haWx0bzph bmR5QHdhcm1jYXQuY29tPj4gd3JvdGU6DQo+DQo+DQo+IFlvdSBjYW4gcHJvYmFibHkgcGlwZWxp bmUgdGhlIENPTk5FQ1QgKyB3cyBoYW5kc2hha2UgdGhvdWdoLCBQYXRyaWNrIHNob3dzIHRoZW0g c2VxdWVudGlhbGx5IGFuZCBJIGRpZG4ndCB0aGluayBhYm91dCBpdCBteXNlbGYuDQo+DQo+DQo+ DQo+IHJpZ2h0LiBUaGUgZXhhbXBsZSBpcyBqdXN0IGZvciBjbGFyaXR5IGFuZCBjYW5ub3Qgc2hv dyBhbGwgZXhwcmVzc2lvbnMgb2YgaDIgZmxvd3MuDQo+DQo+DQo+DQo+IENPTk5FQ1QgKyBEQVRB IGJlZm9yZSB0aGUgcmVzcG9uc2UgaGVhZGVycyBpcyBwcmV0dHkgbXVjaCB0aGUgaDIgYW5hbG9n IG9mIFRDUCBGYXN0IE9wZW4uIFRoZSBkZXZpbCBpcyBpbiB0aGUgZGV0YWlscy4uIFRoYXQncyBh IGdlbmVyYWwgQ09OTkVDVCArIERBVEEgaXNzdWUgbm90IGxpbWl0ZWQgdG8gdGhlIHByb3RvY29s IHVwZ3JhZGUgZGVzY3JpYmVkIGhlcmUgc28gSSBkb24ndCB0aGluayBpdHMgd29ydGggZGlzY3Vz c2lvbiBpbiBhIHdlYnNvY2tldHMgcmZjLg0KPg0KPg0KPg0KPiBJIHRoaW5rIHRoZSBwYXRoIHRv IHN1Y2Nlc3MgaGVyZSBoaW5nZXMgb24gYSB2ZXJ5IHRpZ2h0IHNjb3Bpbmcgb2Ygd29yayBhbmQg dGhlcmVmb3JlIG9wdGltaXppbmcgaGFuZHNoYWtlIGxhdGVuY3kgaXMgYSBub24tZ29hbCBvZiB0 aGlzIGVmZm9ydC4NCj4NCj4NCj4NCj4NCj4NCj4gU3RpbGwgb25seSB0d28gcm91bmQgdHJpcHMu DQo+DQo+DQo+ICAtIFNFVFRJTkdTICAgICAgICAgICAgICAgICAgICAgIC0gU0VUVElOR1MNCj4g IC0gR0VUIC9pbmRleC5odG1sDQo+ICAgICAgICAgICAgICAgICAgLSAyMDAgSEVBREVSUyArIERB VEENCj4NCj4gIC0gOm1ldGhvZCBDT05ORUNUDQo+ICAtIERBVEEgd3MgaGFuZHNoYWtlDQo+ICAg ICAgICAgICAgICAgICAgIC0gMjAwIEhFQURFUlMNCj4gICAgICAgICAgICAgICAgICAgLSBEQVRB IHdzIGhhbmRzaGFrZSBmaW5hbA0KPiAgICAgICAgICAgICAgICAgICAtIERBVEEuLi4NCj4NCj4g IC0gREFUQSAuLi4gICAgICAgICAgICAgLSBEQVRBLi4uDQo+DQo+IFdpdGggdGhlIHBhcnQgb2Yg dGhlIHBpcGVsaW5pbmcgdGhhdCBpcyBsZWdhbCBmb3Igd3MsIHR3byByb3VuZCB0cmlwcyBiZWZv cmUgdGhlIGNsaWVudCBjYW4gc3RhcnQgdG8gc2VuZCBkYXRhIGFuZCAxLjUgYmVmb3JlIHRoZSBz ZXJ2ZXIgY2FuIHNlbmQgZGF0YS4uLiBpZiBpdCdzIHRydWUgdGhlbiB5b3UncmUgcmlnaHQgaXQn cyBub3Qgc28gYmFkLg0KPg0KPiBXZXJlIHlvdSBjb25jZXJuZWQgdGhhdCB0aGUgY2xpZW50IG5l ZWRzIHRvIGxlYXJuIHRoYXQgdGhlIHNlcnZlcg0KPiBzdXBwb3J0cyB3ZWJzb2NrZXRzIGFuZCBu b3QganVzdCA6cHJvdG9jb2w/DQo+DQo+DQo+IE5vIEkganVzdCBmb2xsb3dlZCBQYXRyaWNrJ3Mg c2VxdWVuY2luZzsgaGUgc2hvd3MgdGhlbSBzZXJpYWxpemVkLiAgQnV0IHlvdSdyZSByaWdodCBh dCBsZWFzdCB0aGUgQ09OTkVDVCArIHdzIGhhbmRzaGFrZSBjYW4gcHJvYmFibHkgYmUgcGlwZWxp bmVkLg0KPg0KPiBUaGF0J3MgYWxzbyBnb2luZyB0byBiZSBhIHZhcmlhdGlvbiBmcm9tIG5vcm1h bCBoMiBIRUFERVJTIGZsb3cgaWYgSSB1bmRlcnN0b29kIGl0LCBvbiBvbmUgc3RyZWFtIHRoZXJl IHdpbGwgYmUgRU5EX0hFQURFUnMgY29taW5nIHR3aWNlIChmb3IgdGhlIENPTk5FQ1QgYW5kIHRo ZSB3cyBoYW5kc2hha2Ugc2VwYXJhdGVseSkNCj4NCj4gQW55d2F5IHlvdSBhcmUgcmlnaHQsIGl0 IG1ha2VzIGFueSBkaWZmZXJlbmNlIHdpdGggUFVTSF9QUk9NSVNFIHByb2JhYmx5IG5vdCB3b3J0 aCB0aGUgZWZmb3J0Lg0KPg0KPiAtQW5keQ0KPg0KPg0KPg0KPg0KDQo= --_000_MWHPR21MB01415416D25047646965567B874D0MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhhdmluZyBkaXNjdXNzZWQgd2l0aCBvdXIgZGV2IGxlYWQsIEkgdGhpbmsg dGhlcmXigJlzIG9uZSBvdGhlciBiYXJyaWVyIGhlcmU6Jm5ic3A7IFN0YXRlIG1hY2hpbmUuJm5i c3A7IFdlYlNvY2tldCByZXF1ZXN0cyB0aGF0IHN1cHBvcnQgVXBncmFkZSBoYXZlIHRvIGdvIHRv IHRoZSByZXNvdXJjZSB0byBkZWNpZGUgd2hldGhlciB0byBhY2NlcHQgdGhlbSwgYW5kIGhhdmlu ZyB0d28g4oCcZW5jYXBzdWxhdGVk4oCdIHJlcXVlc3RzIGlzDQogY2hhbGxlbmdpbmcuJm5ic3A7 IExpa2V3aXNlLCB0aGUgY2xpZW50IHNlbmRzIHR3byByZXF1ZXN0cywgd2hpY2ggY29udG9ydHMg dGhlIGV4cG9zZWQgc3RhdGUgbWFjaGluZSBvbiB0aGF0IHNpZGUuJm5ic3A7IFdlIGNvdWxkIGxp ZSBhbmQgdXNlIHRoZSBzdGF0ZXMgdGhhdCBleGlzdCBmb3IgY29ubmVjdGluZyB2aWEgYSBwcm94 eSwgYnV0IGlmIHRoZSBjbGllbnQgaXNu4oCZdCBleHBlY3RpbmcgdG8gdXNlIGEgcHJveHkgdGhh dOKAmXMgZXF1YWxseSBwcm9ibGVtYXRpYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayB3ZeKAmXJlIGFtZW5hYmxlIHRvIGRlZmluaW5nIGEgd2F5IHRvIGRlZmluZSB1cGdyYWRlLW9m LXN0cmVhbSwgYnV0IHRoZSBkb3VibGUtdXBncmFkZSBtb2RlbCBpcyBjaGFsbGVuZ2luZy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgaGUgcG9pbnRlZCBvdXQgdGhhdCBsZWdhY3kgV2Vi U29ja2V0cyBoYWQgdGhlIHVzZWZ1bCBwcm9wZXJ0eSB0aGF0IGFuIHVuc3VwcG9ydGluZyBzZXJ2 ZXIgd291bGQgc2ltcGx5IGhhbmRsZSB0aGUgdmFuaWxsYSBHRVQsIHJhdGhlciB0aGFuIGZhaWxp bmcgZW50aXJlbHkuJm5ic3A7IFRoZSBzZXJ2ZXIgc2V0dGluZyBwYXJ0aWFsbHkgbWl0aWdhdGVz IHRoYXQsIGJ1dCB5b3Ugc3RpbGwgZG9u4oCZdCBrbm93DQo8aT53aGljaDwvaT4gcHJvdG9jb2xz IHRoZSBzZXJ2ZXIgaXMgd2lsbGluZyB0byBjb25zaWRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtlIEJp c2hvcCA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxNywgMjAxNyA5OjM0IEFN PGJyPg0KPGI+VG86PC9iPiAnUGF0cmljayBNY01hbnVzJyAmbHQ7cG1jbWFudXNAbW96aWxsYS5j b20mZ3Q7OyBTdGVmYW4gRWlzc2luZyAmbHQ7c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSZn dDs8YnI+DQo8Yj5DYzo8L2I+IEFuZHkgR3JlZW4gJmx0O2FuZHlAd2FybWNhdC5jb20mZ3Q7OyBN YXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgaHliaSAmbHQ7 aHliaUBpZXRmLm9yZyZndDs7IENvcnkgQmVuZmllbGQgJmx0O2NvcnlAbHVrYXNhLmNvLnVrJmd0 OzsgTWNNYW51cyBQYXRyaWNrICZsdDttY21hbnVzQGR1Y2tzb25nLmNvbSZndDs7IEhUVFAgV29y a2luZyBHcm91cCAmbHQ7aWV0Zi1odHRwLXdnQHczLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtoeWJpXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1jbWFudXMt aHR0cGJpcy1oMi13ZWJzb2NrZXRzLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBpcyBzb21ld2hhdCBjb25qZWN0dXJlLCBzaW5jZSBJIGhhdmVu4oCZ dCBnb25lIG92ZXIgaXQgd2l0aCBvdXIgZGV2IHRlYW0sIGJ1dCBJIHRoaW5rIGl0IHBsYXlzIG91 dCB0byAoYykuJm5ic3A7IFdl4oCZdmUgaGFkIGVub3VnaCBwZW9wbGUgYXNrIGZvciBXZWJTb2Nr ZXQgc3VwcG9ydCwgaXQgd2lsbCBldmVudHVhbGx5IGhhcHBlbiBpZiB0aGVyZeKAmXMgYW4gaW50 ZXJvcGVyYWJsZSB3YXkgdG8gZG8gaXQuJm5ic3A7IElJUkMsDQogVXBncmFkZSBpcyBwbHVnZ2Fi bGUuIFdoZW4gYSBwcm90b2NvbCB1cGdyYWRlcyB0byB3ZWJzb2NrZXQsIHdlIGNoZWNrIGlmIHRo ZXJl4oCZcyBhIGhhbmRsZXIgZm9yIHRoYXQgcHJvdG9jb2wuJm5ic3A7IElmIHNvLCB3ZSByZXR1 cm4gMTAxIGFuZCBnaXZlIGNvbnRyb2wgb2YgdGhlIFRDUCBjb25uZWN0aW9uIHRvIHRoYXQgaGFu ZGxlcjsgdGhlIEhUVFAgbGF5ZXIgYmVjb21lcyBwYXNzdGhyb3VnaC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWYgd2UgaGF2ZSB0byBzdXBwb3J0IHB1bGxpbmcgaW4gSFRUUC8xLjEgcGFyc2lu ZyB0byB0aGF0IHN0cmVhbSBzaW1wbHkgdG8gZG8gYW4gVXBncmFkZSwgdGhhdOKAmXMgYW4gYWRk aXRpb25hbCBzY2VuYXJpbyB3ZSBoYXZlIHRvIHN1cHBvcnQgaW4tbGluZSBmaXJzdCwgYW5kIGFu IGV4dHJhIGxheWVyIHRvIGdvIHBhc3N0aHJvdWdoIGluIHRoZSBob3BlZnVsbHktY29tbW9uIGNh c2UuJm5ic3A7IEnigJlkIHJhdGhlciBiZQ0KIGFibGUgdG8gaGFuZCB0aGUgc3RyZWFtIGRpcmVj dGx5IHRvIHRoZSBXZWJTb2NrZXQgbGlicmFyeSAob3duZWQgYnkgYSBkaWZmZXJlbnQgdGVhbSkg YW5kIGJlIGRvbmUsIGV2ZW4gaWYgaXQgbWVhbnMgdGhlcmXigJlzIGFuIEgyLXNwZWNpZmljIFVw Z3JhZGUgcGF0aC4mbmJzcDsgKFdoaWNoLCBpdCB0dXJucyBvdXQsIHRoZXJlIGlzIGluIHRoaXMg ZHJhZnQgYWxyZWFkeS4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNvdWxkIHN0aWxsIGRl Y2lkZSB0byBzdXBwb3J0IEgyLeKAnHVwZ3JhZGXigJ0tdG8tSDEgaW4gdGhlIGZ1dHVyZSwgYnV0 IGl0IHdvdWxkIGJlIGJlY2F1c2UNCjxpPnRoYXTigJlzPC9pPiBhIGZlYXR1cmUgd2UgZm91bmQg d2UgbmVlZGVkIGZvciBzb21lIHJlYXNvbiwgbm90IGJlY2F1c2UgaXQgd2FzIGFuIGFubm95aW5n IHN0ZXBwaW5nLXN0b25lIHRvIHNvbWV0aGluZyB3ZSBhY3R1YWxseSB3YW50ZWQuJm5ic3A7IChJ biBmYWN0LCBvdXIgbW9zdCBjb21tb24gcmVhc29uIHRvIGlzc3VlIEhUVFBfMV8xX1JFUVVJUkVE IGlzIGNsaWVudCBjZXJ0aWZpY2F0ZXMsIHdoaWNoIHRoaXMgd29u4oCZdCBoZWxwLik8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFBhdHJpY2sgTWNNYW51cyBbPGEgaHJlZj0i bWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tIj5tYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTcsIDIwMTcgNzozNCBB TTxicj4NCjxiPlRvOjwvYj4gU3RlZmFuIEVpc3NpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVm YW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlIj5zdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IFBhdHJpY2sgTWNNYW51cyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBtY21hbnVzQG1vemlsbGEuY29tIj5wbWNtYW51c0Btb3ppbGxhLmNvbTwvYT4mZ3Q7OyBNaWtl IEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20i Pk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgQW5keSBHcmVlbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFuZHlAd2FybWNhdC5jb20iPmFuZHlAd2FybWNhdC5jb208L2E+Jmd0Ozsg TWFydGluDQogVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbSI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDs7IGh5YmkgJmx0OzxhIGhyZWY9 Im1haWx0bzpoeWJpQGlldGYub3JnIj5oeWJpQGlldGYub3JnPC9hPiZndDs7IENvcnkgQmVuZmll bGQgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3J5QGx1a2FzYS5jby51ayI+Y29yeUBsdWthc2EuY28u dWs8L2E+Jmd0OzsgTWNNYW51cyBQYXRyaWNrICZsdDs8YSBocmVmPSJtYWlsdG86bWNtYW51c0Bk dWNrc29uZy5jb20iPm1jbWFudXNAZHVja3NvbmcuY29tPC9hPiZndDs7DQogSFRUUCBXb3JraW5n IEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1odHRwLXdnQHczLm9yZyI+aWV0Zi1odHRw LXdnQHczLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tY21hbnVzLWh0dHBiaXMtaDItd2Vic29ja2V0 cy0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DbGVhcmx5IHN1 YnN0aXR1dGluZyB0aGUgaDEgZXhjaGFuZ2Ugb3V0IGluIGZhdm9yIG9mIGEgbmV3IHdlYnNvY2tl dHMgc3BlY2lmaWMgZXhjaGFuZ2UgdGhhdCBjb250YWluZWQgc3ViLXByb3RvY29sIGFuZCB2ZXJz aW9uIHRva2VucyB3b3VsZCBsb29rIGJldHRlciBvbiBwYXBlci4uLiBJIGFjdHVhbGx5IHRob3Vn aHQgZGl2ZXJnaW5nIGZyb20gNjQ1NSB3b3VsZCBtYWtlIHBlb3BsZSBMRVNTIGxpa2VseSB0bw0K IGltcGxlbWVudC4gTWF5YmUgSSdtIHdyb25nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBsZXQncyBwb2xsIC0gcGxlYXNlIHNwZWFrIHVw IGlmIHlvdSBoYXZlIGEgd3MgaW1wbCAoZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIpOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgc3Bl YyBhZGRlZCBhIG5ldyB3ZWJzb2NrZXRzIHNwZWNpZmljIHBhcmFtZXRlciBuZWdvdGlhdGlvbiBh bmQgcmVtb3ZlZCB0aGUgSDEgc3ludGF4IGl0IHdvdWxkIG1ha2UgbWU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO2FdIE1PUkUgbGlrZWx5 IHRvIGltcGxlbWVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Yl0gTEVTUyBsaWtlbHkgdG8gaW1wbGVtZW50PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtjXSB3b3VsZG4ndCBj aGFuZ2UgbXkgYmVoYXZpb3IgYnV0IEkgbGlrZSBpdCBtb3JlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtkXSB3b3VsZG4ndCBjaGFuZ2Ug bXkgYmVoYXZpb3IgYnV0IGl0IHdvdWxkIGJlIG1vcmUgcGFpbmZ1bCAob3IgbGlrZSBpdCBsZXNz KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ZV0gcmVhbGx5IGRvbid0IGNhcmUgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAxNywgMjAxNyBhdCA0OjU4 IEFNLCBTdGVmYW4gRWlzc2luZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdy ZWVuYnl0ZXMuZGUiIHRhcmdldD0iX2JsYW5rIj5zdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRl PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CiZndDsgQW0gMTYuMTAuMjAxNyB1bSAyMzozMSBzY2hyaWViIFBhdHJpY2sgTWNNYW51cyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tIj5wbWNtYW51c0Btb3ppbGxhLmNv bTwvYT4mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1vbiwgT2N0IDE2LCAyMDE3IGF0IDE6 MTMgUE0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbSI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NClsuLi5dPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBoZWFyIHdoYXQgeW91J3JlIHNheWluZy4u IGJ1dCBJIHRoaW5rIHlvdSdyZSBnb2luZyBhIHRvdWNoIHRvbyBmYXIuIHdlYnNvY2tldCBtZWFu cyA2NDU1IHdoaWNoIGhhcyBhbGwgdGhhdCBoMSBzdHVmZiBhcyBwYXJ0IG9mIGl0cyBjb25maWd1 cmF0aW9uLi4gSSB0aGluayBpdCB3b3VsZCBiZSB0b3RhbGx5IGZhaXIgdG8gc2F5IHN1Y2ggYSBz ZXJ2ZXIgY291bGQgaGF2ZSBhIG1vcmUgY29uc3RyYWluZWQgcGFyc2VyIHRoYXQgZmFpbGVkIGFu eQ0KIG5vbi13cyBjb21wbGlhbnQgaGFuZHNoYWtlIGV2ZW4gaWYgaXQgd2VyZSB2YWxpZCBoMS4g TW9zdGx5IEkgdGhpbmsgaXQgYmVjb21lcyBhbiBpbnNhbmVseSB1Z2x5IHdoYXQgdG8gZG8gd2Vi c29ja2V0IHBhcmFtZXRlciBleGNoYW5nZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIG9m IG9yaWdpbiBpbmZvIChzY2hlbWUgYW5kIGF1dGhvcml0eSkgbW9yZSBhcyBrZXlzIHRvIHJvdXRl IHRoZSBDT05ORUNUIHJlcXVlc3QuLiBpdCdzIDpwcm90b2NvbCB0aGF0IGRlZmluZXMgd2hhdCB0 byBkbyBpbiB0aGUgdHVubmVsLiBJIGFkbWl0IEkgZGlkIGNvbnNpZGVyIGNhbGxpbmcgaXQgOmFs cG4gKHdoaWNoIGhhcyBhIHNpbWlsYXIga2luZCBvZiBwcm9wZXJ0eS4uIGl0cyBhIHJvdXRlIG9m IHNvcnRzIGJ1dCBpdCBkb2Vzbid0DQogYmVhciB0aGUgU0VUVElOR1Mgb3IgbWFnaWMgb2YgaDIp PGJyPg0KPGJyPg0KTWUgc3R1cGlkLiBNZSBhc2tpbmcsIHdoeSBub3QgOnVwZ3JhZGU/PGJyPg0K PGJyPg0KaHQ7ZHIgKGhhdmUgdGltZSwgZG8gcmVhZCk8YnI+DQo8YnI+DQpBcyBwcm9wb3NlZCwg dGhlIENPTk5ORUNUIHNlZW1zIHRvIHNheTogbGV0J3MgdGFsayBIVFRQLzEuMSBvbiB0aGlzIHN0 cmVhbSBmcm9tIG5vdyBvbiwgYWZhaWN0Ljxicj4NCjxicj4NCkZyb20gYSBzZXJ2ZXIgaW1wbGVt ZW50YXRpb24gcG92IHRoYXQgb3BlbnMgYSBsYXJnZXIgY2FuIG9mIHdvcm1zLiBJdCB3b3VsZCBt ZWFuIHdhcm1pbmcgdXAgdGhlIEhUVFAvMS4xIGVuZ2luZSBmb3IgdGhlIERBVEEgb24gdGhpcyBz dHJlYW0uIFRoYXQgbmVlZHMgc29tZSBleHRyYSBjYXJlIHNvIHRoYXQgaXQgZG9lcyBvbmx5IHNh ZmUgdGhpbmdzIGluc2lkZSBhIGgyIHN0cmVhbS4gT24gZmlyc3QgZ2xhbmNlLCBpdCBzZWVtcyB0 byBiZSBlYXNpZXINCiBhbmQgc2FmZXIgdG8gZG8gdGhlIHN0cmVhbSA6dXBncmFkZSBpbnNpZGUg dGhlIGgyIHByb3RvY29sIGhhbmRsaW5nIGl0c2VsZi48YnI+DQo8YnI+DQpKdXN0IG15IGluaXRp YWwgZ3V0IHJlYWN0aW9uLi4uPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4N CjxzcGFuIGNsYXNzPSJob2VuemIiPi1TdGVmYW48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCiZndDsgWW91IGhhdmUga2luZCBvZiBsZXQgdGhlIGNhdCBvdXQgb2Yg dGhlIGJhZyBhdCBqdXN0IGRvaW5nIGFuIGgxIGNvbm5lY3QuIFRoYXQncyBhY3R1YWxseSBwb3Nz aWJsZSB3aXRoIHRoZSBkcmFmdCAob3IgYXQgbGVhc3QgZW52aXNpb25lZCkgYXMgSSBkZWZpbmVk IDpwcm90b2NvbCBzZXBhcmF0ZSBmcm9tIHRoZSB3ZWJzb2NrZXQgc3BlY2lmaWMgc3R1ZmYuLi4g YnV0IEkga2luZGEgaG9wZSB0byBuZXZlciBzcGVhayBvZiBpdCBhZ2FpbiA6KTxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoaXMgaXMgYSB0b3VnaCBvbmUgLSBpdHMgZGVmaW5pdGVseSBnb2luZyBmb3Ig c2ltcGxpY2l0eSBhcyBpdHMgbWFpbiBnb2FsLi4gdGhhdCBtZWFucyBpZ25vcmluZyBtYW55IHBs YWNlcyB0aGF0IGNhbiBiZSBpbXByb3ZlZC4gVGhhdCdzIGEgY2hvaWNlIGJhc2VkIG9uPGJyPg0K Jmd0OyZuYnNwOyBhXSB0aGUgaGlzdG9yeSBvZiBvdGhlciBlZmZvcnRzIHNlZW0gdG8gc3VnZ2Vz dCB0aGVyZSBpcyBubyBzdG9tYWNoIGZvciBjb21wbGV4aXR5L3Jpc2sgaGVyZTxicj4NCiZndDsm bmJzcDsgYl0gd2UgaGVhciBhYm91dCB0aGlzIHByb2JsZW0gZW5vdWdoIHRoYXQgSSB0aGluayBp dHMgd29ydGggc2VlaW5nIGlmIHRoaXMgY2FuIGJlIG0gYWRlIGEgY29uc2Vuc3VzIG12cDxicj4N CiZndDsmbmJzcDsgY10gbXkgYmVsaWVmIHRoYXQgd2Vic29ja2V0cyBpcyBhIHRyYW5zaXRpb25h bCB0ZWNobm9sb2d5IC0gaXQgd2lsbCBiZSBhcm91bmQgZm9yIHllYXJzIGJ1dCBzb21lIGtpbmQg b2YgbmF0aXZlIGh0dHAgd2lsbCBzdXBwbGFudCBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyB5bW12 IChtb3JlIHRoYW4gdXN1YWwgb24gdGhpcyBvbmUhKTxicj4NCiZndDs8YnI+DQomZ3Q7IC1QPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgR2l2ZW4gdGhh dCB5b3XigJlyZSBkb2luZyB0aGUgZnVsbCBVcGdyYWRlLXRvLVdlYlNvY2tldHMgZGFuY2UgaW5z aWRlIHRoZSB0dW5uZWxlZCBjb25uZWN0aW9uLCB3aHkgZG9u4oCZdCB5b3UganVzdCBzYXkgdGhh dCB5b3XigJlyZSBDT05ORUNUaW5nIHRvIGFuIEhUVFAvMS4xIHR1bm5lbD8mbmJzcDsgVGhhdOKA mXMgdGhlbiB0cmVhdGVkIGFzIEhUVFAvMS4xIG92ZXIgVENQLCB3aGljaCBpcyBmdWxseSBhbGxv d2VkIHRvIGRvIFVwZ3JhZGUgaXRzZWxmLiZuYnNwOyBJZiB5b3XigJlyZQ0KIHN1cmUgdGhhdOKA mXMgdGhlIHBhdGggeW91IHdhbnQsIHRoZW4gc2ltcGx5IHNheSBpbiB0aGUgSFRUUC8yIGxheWVy IHRoYXQgeW914oCZcmUgZG9pbmcgSFRUUC8xLjEgaW5zaWRlIHRoZSBzdHJlYW0uJm5ic3A7IElu Y2lkZW50YWxseSwgdGhhdCBtaWdodCBiZSBhIG5pY2UgYWx0ZXJuYXRpdmUgZm9yIGRlYWxpbmcg d2l0aCBIVFRQXzFfMV9SRVFVSVJFRCByZXNwb25zZXMsIHRvbyE8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb206IFBhdHJpY2sgTWNNYW51cyBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbSI+cG1jbWFudXNAbW96aWxsYS5jb208L2E+ XTxicj4NCiZndDsgU2VudDogTW9uZGF5LCBPY3RvYmVyIDE2LCAyMDE3IDU6MTYgQU08YnI+DQom Z3Q7IFRvOiBBbmR5IEdyZWVuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB3YXJtY2F0LmNvbSI+ YW5keUB3YXJtY2F0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogTWFydGluIFRob21zb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29u QGdtYWlsLmNvbTwvYT4mZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0OzxhIGhyZWY9Im1haWx0bzpw bWNtYW51c0Btb3ppbGxhLmNvbSI+cG1jbWFudXNAbW96aWxsYS5jb208L2E+Jmd0OzsgaHliaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmh5YmlAaWV0Zi5vcmciPmh5YmlAaWV0Zi5vcmc8L2E+Jmd0Ozsg Q29yeSBCZW5maWVsZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcnlAbHVrYXNhLmNvLnVrIj5jb3J5 QGx1a2FzYS5jby51azwvYT4mZ3Q7Ow0KIFBhdHJpY2sgTWNNYW51cyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1jbWFudXNAZHVja3NvbmcuY29tIj5tY21hbnVzQGR1Y2tzb25nLmNvbTwvYT4mZ3Q7OyBI VFRQIFdvcmtpbmcgR3JvdXAgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWh0dHAtd2dAdzMub3Jn Ij5pZXRmLWh0dHAtd2dAdzMub3JnPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbaHli aV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tY21hbnVzLWh0dHBiaXMtaDIt d2Vic29ja2V0cy0wMC50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBNb24sIE9jdCAxNiwg MjAxNyBhdCAxMjo0NCBBTSwgQW5keSBHcmVlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAd2Fy bWNhdC5jb20iPmFuZHlAd2FybWNhdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgWW91IGNhbiBwcm9iYWJseSBwaXBlbGluZSB0aGUgQ09OTkVDVCAmIzQz OyB3cyBoYW5kc2hha2UgdGhvdWdoLCBQYXRyaWNrIHNob3dzIHRoZW0gc2VxdWVudGlhbGx5IGFu ZCBJIGRpZG4ndCB0aGluayBhYm91dCBpdCBteXNlbGYuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyByaWdodC4gVGhlIGV4YW1wbGUgaXMganVzdCBmb3IgY2xhcml0eSBh bmQgY2Fubm90IHNob3cgYWxsIGV4cHJlc3Npb25zIG9mIGgyIGZsb3dzLjxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ09OTkVDVCAmIzQzOyBEQVRBIGJlZm9yZSB0aGUg cmVzcG9uc2UgaGVhZGVycyBpcyBwcmV0dHkgbXVjaCB0aGUgaDIgYW5hbG9nIG9mIFRDUCBGYXN0 IE9wZW4uIFRoZSBkZXZpbCBpcyBpbiB0aGUgZGV0YWlscy4uIFRoYXQncyBhIGdlbmVyYWwgQ09O TkVDVCAmIzQzOyBEQVRBIGlzc3VlIG5vdCBsaW1pdGVkIHRvIHRoZSBwcm90b2NvbCB1cGdyYWRl IGRlc2NyaWJlZCBoZXJlIHNvIEkgZG9uJ3QgdGhpbmsgaXRzIHdvcnRoIGRpc2N1c3Npb24gaW4g YSB3ZWJzb2NrZXRzDQogcmZjLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgSSB0aGluayB0aGUgcGF0aCB0byBzdWNjZXNzIGhlcmUgaGluZ2VzIG9uIGEgdmVyeSB0aWdo dCBzY29waW5nIG9mIHdvcmsgYW5kIHRoZXJlZm9yZSBvcHRpbWl6aW5nIGhhbmRzaGFrZSBsYXRl bmN5IGlzIGEgbm9uLWdvYWwgb2YgdGhpcyBlZmZvcnQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFN0aWxsIG9ubHkgdHdvIHJvdW5k IHRyaXBzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAtIFNFVFRJTkdTJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAtIFNFVFRJTkdTPGJyPg0KJmd0OyZuYnNwOyAtIEdFVCAvaW5kZXgu aHRtbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAtIDIwMCBIRUFERVJTICYjNDM7IERBVEE8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAtIDptZXRob2QgQ09OTkVDVDxicj4NCiZndDsmbmJzcDsgLSBEQVRBIHdz IGhhbmRzaGFrZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstIDIwMCBIRUFERVJTPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOy0gREFUQSB3cyBoYW5kc2hha2UgZmluYWw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 LSBEQVRBLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgLSBEQVRBIC4uLiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gREFUQS4uLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFdpdGggdGhlIHBhcnQgb2YgdGhlIHBpcGVsaW5pbmcgdGhhdCBpcyBsZWdhbCBm b3Igd3MsIHR3byByb3VuZCB0cmlwcyBiZWZvcmUgdGhlIGNsaWVudCBjYW4gc3RhcnQgdG8gc2Vu ZCBkYXRhIGFuZCAxLjUgYmVmb3JlIHRoZSBzZXJ2ZXIgY2FuIHNlbmQgZGF0YS4uLiBpZiBpdCdz IHRydWUgdGhlbiB5b3UncmUgcmlnaHQgaXQncyBub3Qgc28gYmFkLjxicj4NCiZndDs8YnI+DQom Z3Q7IFdlcmUgeW91IGNvbmNlcm5lZCB0aGF0IHRoZSBjbGllbnQgbmVlZHMgdG8gbGVhcm4gdGhh dCB0aGUgc2VydmVyPGJyPg0KJmd0OyBzdXBwb3J0cyB3ZWJzb2NrZXRzIGFuZCBub3QganVzdCA6 cHJvdG9jb2w/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE5vIEkganVzdCBmb2xsb3dl ZCBQYXRyaWNrJ3Mgc2VxdWVuY2luZzsgaGUgc2hvd3MgdGhlbSBzZXJpYWxpemVkLiZuYnNwOyBC dXQgeW91J3JlIHJpZ2h0IGF0IGxlYXN0IHRoZSBDT05ORUNUICYjNDM7IHdzIGhhbmRzaGFrZSBj YW4gcHJvYmFibHkgYmUgcGlwZWxpbmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQncyBhbHNv IGdvaW5nIHRvIGJlIGEgdmFyaWF0aW9uIGZyb20gbm9ybWFsIGgyIEhFQURFUlMgZmxvdyBpZiBJ IHVuZGVyc3Rvb2QgaXQsIG9uIG9uZSBzdHJlYW0gdGhlcmUgd2lsbCBiZSBFTkRfSEVBREVScyBj b21pbmcgdHdpY2UgKGZvciB0aGUgQ09OTkVDVCBhbmQgdGhlIHdzIGhhbmRzaGFrZSBzZXBhcmF0 ZWx5KTxicj4NCiZndDs8YnI+DQomZ3Q7IEFueXdheSB5b3UgYXJlIHJpZ2h0LCBpdCBtYWtlcyBh bnkgZGlmZmVyZW5jZSB3aXRoIFBVU0hfUFJPTUlTRSBwcm9iYWJseSBub3Qgd29ydGggdGhlIGVm Zm9ydC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtQW5keTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB01415416D25047646965567B874D0MWHPR21MB0141namp_-- From nobody Tue Oct 24 22:03:20 2017 Return-Path: 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 C63AB13B138 for ; Tue, 24 Oct 2017 22:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=oBu/TB+u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vh/JprN2 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 TSUdqg4rS3VX for ; Tue, 24 Oct 2017 22:03:16 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA3A13B0F4 for ; Tue, 24 Oct 2017 22:03:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D3A7E20CB2; Wed, 25 Oct 2017 01:03:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 25 Oct 2017 01:03:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=OPK2s+msH7pI0YkcS6qy0n9845fzdY0VbH+9bwGjp/I=; b=oBu/TB+u Zg9IOHtXzTGqVZ7YYmKrc277t5/nsfsTuDtfOPzoKHehS22f6lg7tg3SjZuMu1zv 1X1CpMy2dQqaYhGnpo2gUNyq88AMP9wuBZWbGGfQb/PSdBf5kw3Lhql07edr2wDg izujnFDdCEoeyFh0eaD3d0QhUyXZpC+0/pm5KrU8aME5uecKCVelLfoGLoYYWIYF gfkRcCcCr6BD2e8EV207DuE3GJc0dDfcmFvJXwH0Jji/h9Q8ryfI0VPm9e+GlLn4 YcSnSWp1bqRtY87X0TgO8Wi7X37uUq5Aa4xsg+JUPj32bAtU2qa5g6IDu4uYg6DD qV6sbmzFoc6rmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OPK2s+msH7pI0YkcS6qy0n9845fzd Y0VbH+9bwGjp/I=; b=Vh/JprN2jdrRkFWbl8Z1/Y88QJnN2Lxv9idX6aJ7LpU5M 4TcZzVjzlYuHimfJIv2tx0rg/NJE6A9H/Th1ocC0dV7/ygu4qVwT3T0b8U0Q3c1j rJcWby7CYRrFYk419zoc7FEFsEptZprVwW90wdz6wQvV+TA+Visso6nA8GuoqkKb 2oxk/xG/E7gD30hc8JTxJ9x2bjwrRdZWsyvQsB6LhdjydAEDRQCgwmD+DE7znf8B 3mne9d7lqJtKJmWm9HHrDJMbSjeWVZxi1vG4d8Gh3yP2GokXxIozaTI9Dwng/Z9R rYwlFMqAdb6CnDpbMjOnde4lJwd1UIATe7LNfdm6A== X-ME-Sender: Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 6660C7F967; Wed, 25 Oct 2017 01:03:14 -0400 (EDT) From: Mark Nottingham Message-Id: <65E0F440-C2FC-44B5-BF26-05078C8CBBBD@mnot.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_23857E94-65AD-4A93-A07E-D8F1418C9EEE" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Wed, 25 Oct 2017 16:03:10 +1100 In-Reply-To: Cc: HTTP Working Group , hybi To: Patrick McManus References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 05:03:19 -0000 --Apple-Mail=_23857E94-65AD-4A93-A07E-D8F1418C9EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey Patrick, Catching up after travel... The only thing that I don't like about this is covered in your FAQ: > # Instead of overloading CONNECT, why not a new TUNNEL method? > > Methods are generally end to end and, more importantly, HTTP version = independent. CONNECT is already a special snowflake in this regard. Note = that the only method 7540 defines is CONNECT - because all the others = are inherited from the semantic layer of 723x. Extending it is fairly = natural as its defined specifically for HTTP/2 while a new method would = not be well known as a version specific mechanism. But 7540 didn't *define* CONNECT, it just adapted how it's used on the = wire; the semantics are still "Hey proxy, give me a tunnel to THAT = host." Importantly, CONNECT here isn't being used to talk to a proxy, it's for = an origin. And, given how much extra machinery is being defined, I don't = see the downside of defining a new method with the specific semantics = you're looking for, rather than muddying those of an existing method = (which might have bad interactions with current configurations, tools, = etc.). Cheers, > On 16 Oct 2017, at 1:12 am, Patrick McManus = wrote: >=20 > FYI - also see = https://github.com/mcmanus/draft-h2ws/blob/master/README.md = >=20 > Comments, expressions of interest, etc are very welcome. >=20 >=20 > ---------- Forwarded message ---------- > From: > > Date: Sun, Oct 15, 2017 at 10:08 AM > Subject: New Version Notification for = draft-mcmanus-httpbis-h2-websockets-00.txt > To: Patrick McManus > >=20 >=20 >=20 > A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt > has been successfully submitted by Patrick McManus and posted to the > IETF repository. >=20 > Name: draft-mcmanus-httpbis-h2-websockets > Revision: 00 > Title: Bootstrapping WebSockets with HTTP/2 > Document date: 2017-10-15 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-0= 0.txt = > Status: = https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ = > Htmlized: = https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-= 00 = >=20 >=20 > Abstract: > This document defines a mechanism for running the WebSocket = Protocol > [RFC6455] over a single stream of an HTTP/2 connection. >=20 >=20 >=20 >=20 > 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 = . >=20 > The IETF Secretariat >=20 >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_23857E94-65AD-4A93-A07E-D8F1418C9EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hey = Patrick,

Catching up = after travel...

The only thing that I don't like about this is covered in = your FAQ:

> = # Instead of overloading CONNECT, why not a new TUNNEL method?
>
> Methods are generally end to end and, = more importantly, HTTP version independent. CONNECT is already a special = snowflake in this regard. Note that the only method 7540 defines is = CONNECT - because all the others are inherited from the semantic layer = of 723x. Extending it is fairly natural as its defined specifically = for HTTP/2 while a new method would not be well known as a version = specific mechanism.

But 7540 didn't *define* CONNECT, it just adapted how it's = used on the wire; the semantics are still "Hey proxy, give me a tunnel = to THAT host."

Importantly, CONNECT here isn't being used to talk to a = proxy, it's for an origin. And, given how much extra machinery is being = defined, I don't see the downside of defining a new method with the = specific semantics you're looking for, rather than muddying those of an = existing method (which might have bad interactions with current = configurations, tools, etc.).

Cheers,


On 16 Oct 2017, at 1:12 am, Patrick McManus <mcmanus@ducksong.com> wrote:

FYI - also see https://github.com/mcmanus/draft-h2ws/blob/master/README.md=

Comments, = expressions of interest, etc are very welcome.


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: = Sun, Oct 15, 2017 at 10:08 AM
Subject: New Version = Notification for draft-mcmanus-httpbis-h2-websockets-00.txt
To: Patrick McManus <mcmanus@ducksong.com>



A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt
has been successfully submitted by Patrick McManus and posted to the
IETF repository.

Name:          =  draft-mcmanus-httpbis-h2-websockets
Revision:       00
Title:          Bootstrapping WebSockets with = HTTP/2
Document date:  2017-10-15
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00


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



--
Mark Nottingham  =  https://www.mnot.net/

= --Apple-Mail=_23857E94-65AD-4A93-A07E-D8F1418C9EEE-- From nobody Thu Oct 26 10:32:15 2017 Return-Path: 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 C671D13F40C for ; Thu, 26 Oct 2017 10:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 0UxxmxN0lwkZ for ; Thu, 26 Oct 2017 10:32:13 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88813F3C7 for ; Thu, 26 Oct 2017 10:32:13 -0700 (PDT) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 7938B3A0A1 for ; Thu, 26 Oct 2017 13:32:12 -0400 (EDT) Received: by mail-lf0-f45.google.com with SMTP id w21so4629321lfc.6 for ; Thu, 26 Oct 2017 10:32:12 -0700 (PDT) X-Gm-Message-State: AMCzsaXFAWAC9bgqXYjVpvPJ+ASSm9iLdDynk/m6AQHarwxSTulAibjO e0TCkKJeN/7/UDq+gt5Rt84pahF/tj6lPPBuDns= X-Google-Smtp-Source: ABhQp+SaVqcHSp+NUcb0DdbYGCSAAUk75wrYIYEXnmZUwxWosUPTjLA0OhwnHX3ZCluC7K6G9chFbeujzv/YaXMR8GU= X-Received: by 10.46.56.20 with SMTP id f20mr10430905lja.189.1509039131338; Thu, 26 Oct 2017 10:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Thu, 26 Oct 2017 10:32:10 -0700 (PDT) In-Reply-To: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Thu, 26 Oct 2017 13:32:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="089e0823e0b4602daf055c768dfd" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:32:15 -0000 --089e0823e0b4602daf055c768dfd Content-Type: text/plain; charset="UTF-8" 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: Date: Thu, Oct 26, 2017 at 1:30 PM Subject: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt To: Patrick McManus 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 --089e0823e0b4602daf055c768dfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 dra= ft-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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mcmanus-httpbis-h2-websockets
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bootstrapping WebSockets with HTTP= /2
Document date:=C2=A0 2017-10-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mc= manus-httpbis-h2-websockets-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-= websockets/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets= -01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mcmanus-h= ttpbis-h2-websockets-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mcmanus-= httpbis-h2-websockets-01

Abstract:
=C2=A0 =C2=A0This document defines a mechanism for running the WebSocket Pr= otocol
=C2=A0 =C2=A0[RFC6455] over a single stream of an HTTP/2 connection.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e0823e0b4602daf055c768dfd-- From nobody Thu Oct 26 14:47:27 2017 Return-Path: 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 4295F13F61C for ; Thu, 26 Oct 2017 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kaazing-com.20150623.gappssmtp.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 Ul635gEIkkoW for ; Thu, 26 Oct 2017 14:47:23 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 8E4B01397F3 for ; Thu, 26 Oct 2017 14:47:23 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id i35so3520987uah.9 for ; Thu, 26 Oct 2017 14:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaazing-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e8ja3jA8v1VQLqBU0Ssxu9lOLMyeiGb5zRC9qAgyOE0=; b=U5Bsu7feWWADTffGSPyJvN12XkfsLVTtXGx28B5/LqBatMmnSaou8rfgl1qorm1j3Z TQaa0G5E//FqvueC60lRV7c5SSIMIZlxcRDL1Ts39ypQLlgy7oShQop/cuyu4oUattUU YpFGFyRFu+SgCEGFMwxiGeBeYdx/LDBkQ2shElm+wAcDqdAxiLdKXKZ0EIn9zM5BOQq6 5H3YED2tfVvWRoVYUItuTCnDgevz93IIx/b3zYNHc29zJGYbuVxqXUp287lcjbn525hq 58o6ePJfq7Y1IJ7iowCZMx96Td7xSZUgw9XaOBvQNvFD0ccFTMHJkqZoH1w9n6B32dQV bOGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e8ja3jA8v1VQLqBU0Ssxu9lOLMyeiGb5zRC9qAgyOE0=; b=atAVZMiOesULnScJyWwPIQo5oCOWsjTqvR1V4RtOfNucgnF9ZDXPYMZcaed4HHOvKA SismYFHn8ZU540pefFH6Bi5E5BmRZOs9m8nYThRJnQ5Wuo3YO75/i+A+GY1n4Mves64u PHa3kAjmHA9S7XSAERwmZ8kAaf4Eb/dB0R3S2jAY0VNb3YU3QEP++zTetJQzVpAqJoLk 0sOpDQmI8bD5scTxgmAzMhepEa5bOnBc0fKvr1Mn5nCN8OvZp4zzpQWoGIUvvNSwGcv5 XtYNk0fzid/NxzFNkURnzIhYpJCvQ5+8Xgd3PQr2aGdoLMpGYHwuCccBlUzRu2zppRU+ EjIA== X-Gm-Message-State: AMCzsaUuhbG2djNnRHOAU3IiwZWovw5wqUvcsuZpGQluwwtcFtmK6vIc wx6B16ZrlSK393JYtuLe0ZquO8MQZDL8BSaAE9u4Dg== X-Google-Smtp-Source: ABhQp+Tx1wZ+lfiWbvEbSSWModMEM8l1mjnM+KzYw9MfWZx0ZTnp8iPThyM19crBG26eCAzYa4bre7pde/ZaQA6t1IU= X-Received: by 10.159.39.97 with SMTP id a88mr5601879uaa.31.1509054442472; Thu, 26 Oct 2017 14:47:22 -0700 (PDT) MIME-Version: 1.0 References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> In-Reply-To: From: John Fallows Date: Thu, 26 Oct 2017 21:47:11 +0000 Message-ID: To: Patrick McManus Cc: hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="94eb2c122d0cfd9a72055c7a1dab" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 21:47:26 -0000 --94eb2c122d0cfd9a72055c7a1dab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D 1 HEADERS + END_HEADERS :method =3D TUNNEL :protocol =3D websocket :scheme =3D https :path =3D /chat :authority =3D server.example.com:443 origin =3D http://www.example.com sec-websocket-protocol =3D chat, superchat sec-websocket-version =3D 13 HEADERS + END_HEADERS :status =3D 200 sec-websocket-protocol =3D 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 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: > Date: Thu, Oct 26, 2017 at 1:30 PM > Subject: New Version Notification for > draft-mcmanus-httpbis-h2-websockets-01.txt > To: Patrick McManus > > > > 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=3Ddraft-mcmanus-httpbis-h2-websockets-0= 1 > > 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 > --=20 *John Fallows* CTO* | *=F0=9F=93=9E+1.415.215.6597 *----------------------------------------------------------------------* KAAZING >|< when real-time matters=E2=84=A2 kaazing.com/kwic | Blog | Twitter --94eb2c122d0cfd9a72055c7a1dab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Patrick,

Many thanks for spearheadin= g this latest effort to define WebSocket over HTTP/2, it's really encou= raging to see the progress.

I recall from the earl= y 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 becaus= e the HTTP/1.1 layer on the server now needed to know how to special case t= he 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 initi= al content.

Ultimately, that approach was dropped = in favor of a single request-response to define the WebSocket handshake ove= r HTTP/1.1, with no additional request payload needed to process the handsh= ake, making the implementation simpler and with better abstraction layering= .

The current proposal for WebSocket over HTTP/2 s= eems to be following a similar approach to that described above at the mome= nt, with the HEADERS frame (requiring special-case processing of CONNECT) a= nd first DATA frame both needed to process the server-side WebSocket handsh= ake over HTTP/2.

Suggest we instead fold the origin and relevant RFC-6455 defined HTTP header= s into the HEADERS frame for simplicity, recognizing as Mark noted that CON= NECT is not really intended for use directly at the origin server, and inst= ead use a TUNNEL method with corresponding :protoc= ol pseudo-header, where the value of the TUNNEL :protocol pseudo-header drives the expectation of additional HT= TP/2 headers that should be present.

[[ From Client ]]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [[ From Server ]]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 SETTINGS
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ENABLE_T= UNNEL_PROTOCOL =3D 1

HEADERS + END_HEADERS
=
=C2=A0 =C2=A0:method =3D TUNNEL
<= div>=C2=A0 =C2=A0:protocol =3D websocket
=C2=A0 =C2=A0:scheme =3D https
=C2=A0 =C2=A0:path =3D /chat
=C2=A0 =C2=A0:authority =3D server.example.com:443
=C2=A0 =C2=A0origin =3D=C2=A0http://www.example.com
=C2=A0 =C2=A0sec-websocket-protocol =3D chat,=C2=A0<= span style=3D"font-family:monospace;font-size:10.5625px">superchat
=C2=A0 =C2=A0sec-websocket-version =3D= 13

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HEADERS + END_HEADERS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 :status =3D 200
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0sec-websocket-protocol =3D ch= at

=C2=A0 =C2=A0DATA
=C2=A0 =C2=A0WebSocket Frames

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 DATA + END_STREAM
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 W= ebSocket=C2=A0Frames

=C2=A0 =C2=A0DATA= + END_STREAM
<= span style=3D"font-size:10.5625px">=C2=A0 =C2=A0WebSocket=C2=A0Frames

No= te also that the scheme is "https" rather than "wss" be= cause the HTTP request is still "https" until *after* the TUNNEL = has been established, and the TUNNEL protocol being selected is based on :protocol header ra= ther than the :scheme header.
Hope this is helpful and interested to hear y= our thoughts and feedback.

K= ind Regards,
John Fallows
CTO, Ka= azing

On Th= u, Oct 26, 2017 at 10:32 AM Patrick McManus <pmcmanus@mozilla.com> wrote:
This is an updated based on the directi= on 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&= gt;
Date: Thu, Oct 26, 2017 at 1:30 PM
Subject: New Version No= tification for draft-mcmanus-httpbis-h2-websockets-01.txt
To: Patrick Mc= Manus <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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mcmanus-httpbis-h2-webs= ockets
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bootstrapping WebSockets with HTTP= /2
Document date:=C2=A0 2017-10-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mcmanus= -httpbis-h2-websockets-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-webso= ckets/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-01 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-= websockets-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mcmanus-httpb= is-h2-websockets-01

Abstract:
=C2=A0 =C2=A0This document defines a mechanism for running the WebSocket Pr= otocol
=C2=A0 =C2=A0[RFC6455] over a single stream of an HTTP/2 connection.




Please note that it may take a couple of minutes from the time of submissio= n
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=C2=A0 | =C2=A0= =F0=9F=93=9E+1.415.215.6597
--------------------------------------------------------------= --------
= KAAZING=C2=A0=C2=A0=C2=A0w= hen real-time matters=E2=84=A2
kaazin= g.com/kwic=C2=A0=C2=A0| =C2=A0Blog=C2=A0=C2=A0| =C2=A0Twitter=C2=A0
<= div>
<= /div>
--94eb2c122d0cfd9a72055c7a1dab-- From nobody Thu Oct 26 16:07:39 2017 Return-Path: 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 ; 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 ; 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 ; Thu, 26 Oct 2017 16:07:34 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id a132so8317933oih.11 for ; 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: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Fri, 27 Oct 2017 10:07:32 +1100 Message-ID: To: John Fallows Cc: Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="001a113de3acb3425f055c7b3c50" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 23:07:37 -0000 --001a113de3acb3425f055c7b3c50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 presen= t. > > [[ From Client ]] [[ From Server ]] > > SETTINGS > ENABLE_TUNNEL_PROTOCOL =3D 1 > > HEADERS + END_HEADERS > :method =3D TUNNEL > :protocol =3D websocket > :scheme =3D https > :path =3D /chat > :authority =3D server.example.com:443 > origin =3D http://www.example.com > sec-websocket-protocol =3D chat, superchat > sec-websocket-version =3D 13 > > HEADERS + END_HEADERS > :status =3D 200 > sec-websocket-protocol =3D 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, a= nd > 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 > 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: >> Date: Thu, Oct 26, 2017 at 1:30 PM >> Subject: New Version Notification for draft-mcmanus-httpbis-h2- >> websockets-01.txt >> To: Patrick McManus >> >> >> >> 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=3Ddraft-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* | *=F0=9F=93=9E+1.415.215.6597 > *----------------------------------------------------------------------* > KAAZING >|< when real-time matters=E2=84=A2 > kaazing.com/kwic | Blog > | Twitter > --001a113de3acb3425f055c7b3c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that John is right here.=C2=A0 Packing the we= bsocket handshake into DATA frames is more complicated than just using the = headers.=C2=A0 The main difference then between this handshake and the webs= ockets one is:

* it's HTTP/2
* it mi= ght 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 b= etween usages (proxy vs. origin).=C2=A0 A natural lightweight implementatio= n of this has the server add proxy code that forwards the tunnel to a webso= cket server.=C2=A0 That proxy would need to perform the old-school 6455 han= dshake with the websocket server, but could construct that from the headers= of the CONNECT request.=C2=A0 The handling of the header might be differen= t, but the DATA frames are handled just like a CONNECT tunnel.=C2=A0 That s= aid, 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 th= e 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 unsupp= orted protocol.=C2=A0 And you probably want a registry for :protocol values= (yay).



On Fri, Oct 27, 2017 at 8:47 AM, John F= allows <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 aro= und the time we moved it from W3C HTML5 to IETF HyBi, that the client hands= hake required sending additional content after the GET w/ Upgrade HTTP/1.1 = request.

This approach led to increased implementa= tion 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 W= ebSocket handshake over HTTP/1.1, with no additional request payload needed= to process the handshake, making the implementation simpler and with bette= r abstraction layering.

The current proposal for W= ebSocket over HTTP/2 seems to be following a similar approach to that descr= ibed above at the moment, with the HEADERS frame (requiring special-case pr= ocessing 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-64= 55 defined HTTP headers into the HEADERS frame for simplicity, recognizing = as Mark noted that CONNECT is not really intended for use directly at the o= rigin server, and instead use a TUNNEL method with corresponding :protocol pseudo-header, where the value of the TUNNE= L :protocol pseudo-header drives the expect= ation of additional HTTP/2 headers that should be present.

[[ From Client ]]=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [[ Fr= om Server ]]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SETTINGS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ENABLE_TUNNEL_PROTOCOL =3D 1

HEADERS + EN= D_HEADERS
=C2=A0 =C2=A0:method = =3D TUNNEL
=C2=A0 =C2=A0:protocol= =3D websocket
=C2=A0 =C2=A0:sche= me =3D https
=C2=A0 =C2=A0:path = =3D /chat
=C2=A0 =C2=A0:authority= =3D server.exa= mple.com:443
=C2=A0 =C2= =A0origin =3D=C2=A0http://www.example.com
=C2=A0 =C2=A0sec-websocket-protocol =3D chat,=C2=A0superchat
=C2=A0 =C2=A0sec-websocket-version =3D 13

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 HEADERS + END_HEADERS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :status =3D 200
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sec-w= ebsocket-protocol =3D chat

=C2=A0 =C2=A0DATA=
=C2=A0 =C2=A0WebSocket Frames

=
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D= ATA + END_STREAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WebSocket=C2=A0Frames

=C2=A0= =C2=A0DATA + END_STREAM
<= span style=3D"font-size:10.5625px">=C2=A0 =C2=A0WebSocket=C2=A0Frames

No= te also that the scheme is "https" rather than "wss" be= cause the HTTP request is still "https" until *after* the TUNNEL = has been established, and the TUNNEL protocol being selected is based on :protocol header ra= ther than the :scheme header.
Hope this is helpful and interested to hear your thought= s and feedback.

Kind Regards,
John Fallo= ws
CTO, Kaazing

On Thu, Oct 26, 2017 at 10:32 AM Patr= ick McManus <p= mcmanus@mozilla.com> wrote:
This is an updat= ed 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&= gt;
Date: Thu, Oct 26, 2017 at 1:30 PM
Subject: New Version No= tification for draft-mcmanus-httpbis-h2-websockets-01.txt
To: Patri= ck McManus <mc= manus@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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mcmanus-httpbis-h2-websockets
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bootstrapping WebSockets with HTTP= /2
Document date:=C2=A0 2017-10-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mc= manus-httpbis-h2-websockets-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-= websockets/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets= -01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mcmanus-h= ttpbis-h2-websockets-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mcmanus-= httpbis-h2-websockets-01

Abstract:
=C2=A0 =C2=A0This document defines a mechanism for running the WebSocket Pr= otocol
=C2=A0 =C2=A0[RFC6455] over a single stream of an HTTP/2 connection.




Please note that it may take a couple of minutes from the time of submissio= n
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=C2= =A0 | =C2=A0=F0=9F=93=9E+1.415.215.6597
<= font color=3D"#cccccc">-----------------------------------------------= -----------------------
KAAZING=C2=A0>|<=C2=A0= =C2=A0when real-time matters=E2=84=A2
<= font face=3D"arial, helvetica, sans-serif">kaazing.com/kwic=C2=A0=C2=A0| =C2=A0Blo= g=C2=A0= =C2=A0| =C2=A0Twitter=C2=A0

--001a113de3acb3425f055c7b3c50-- From nobody Thu Oct 26 16:39:33 2017 Return-Path: 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 3DB3413F48B for ; Thu, 26 Oct 2017 16:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=VQDxTQEO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T0zhKbJU 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 bp7qMDiq3EMy for ; Thu, 26 Oct 2017 16:39:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534281389AC for ; Thu, 26 Oct 2017 16:39:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C21B32081E; Thu, 26 Oct 2017 19:39:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 26 Oct 2017 19:39:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=hDLRi+fRSI+CIKXOpv7o5V7cslkOu +7Mx74/OjmPdyE=; b=VQDxTQEODC8ak+kQ4OEmL84ED7zxvZO5uxM6kWSUJBgAZ UzFzHgNNWJmHG4+JzKpTGVvMTOMmP5nvexILp9sHdw9AfPS6+LSUD1ndfyn0Dh1P x/d83PZloNDrR7SejUj3+IBxdQdaDxekmJmDXLBHLQ7/i1CiqQZdOfpBhPYyUfT+ 875/awd06L5UfHHotVoASWnG7qqvFFPm39bagZsmNfaZ0OlzXi2OCL8z1+WBaRua 8X//CTOQKeDIepmUEOqm2LXpH5Y0yB1w+246nGnTCIS3Rw44agjKrj5rq6jS8OTC y5tmLJUzzBvmSoi2JwM7NA/tZNfHJH1vBPL6t+APw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hDLRi+ fRSI+CIKXOpv7o5V7cslkOu+7Mx74/OjmPdyE=; b=T0zhKbJUjlP37Q89RBeSPW LVV5liK13TCOzLA5C4QrE4UyvUogkjDFGQb6g91MiWiZscekjfL9TawiCNanVI3x 5JFM/O1WNa6OnFh7uylGuRKF9Mbid7PVFoOQUV5PHaJoVVzPTHYltW2NGqy7bYdt 4V1PAYWfMn1BfqcaPc0uHVn8cKn18Fvv5TNzXVEj+4q4N7JqbCy5OczIu9Lw7Cq7 jKULGnWlt0u+x1AFH+Nnh7mX0BWxfynb8TdUm7tdCI6j4CaHGG4LUR1UmDxTW7T2 iqhTd6XQ2gXbca+zP5P3Kuf61jBvLfUpURLL8NL82zspckVj5wVg8HPM/Ys6J05Q == X-ME-Sender: Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 27D5B7F97C; Thu, 26 Oct 2017 19:39:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: Date: Fri, 27 Oct 2017 10:39:23 +1100 Cc: John Fallows , Patrick McManus , hybi , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <76309743-EB28-4B47-BB94-254421538582@mnot.net> References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 23:39:32 -0000 On 27 Oct 2017, at 10:07 am, Martin Thomson = wrote: >=20 > 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. Just to give some context as to why I don't think it's a subtle change = -- consider OWASP's mod_security CRS, which is the basis of most WAF = products. It has baked-in assumptions about the semantics of CONNECT; = e.g., = That is pretty widely deployed, and just one example. Don't assume that = HTTP is just a two-party protocol, even over HTTPS. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Oct 26 16:41:28 2017 Return-Path: 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 4F39D13B472 for ; Thu, 26 Oct 2017 16:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FqqtznM5zLtN for ; Thu, 26 Oct 2017 16:41:25 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6557C1389AC for ; Thu, 26 Oct 2017 16:41:25 -0700 (PDT) To: John Fallows , Patrick McManus Cc: hybi , HTTP Working Group References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Andy Green Message-ID: Date: Fri, 27 Oct 2017 07:40:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 23:41:27 -0000 On 10/27/2017 05:47 AM, John Fallows wrote: > 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 While I think the first draft, second draft or this suggestion are already good enough and get the result of eliminating the tcp + tls setup for ws needed today, I also thought that was what was going to happen in the second draft. > 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 :protocolheader > rather than the :schemeheader. > > Hope this is helpful and interested to hear your thoughts and feedback. This is also simpler for me in two ways, a) headers remain headers and b) we don't need a new state machine to parse the DATA before it becomes ws traffic... DATA is only used to carry the tunnelled traffic which is better. If you use a funky :method + :protocol or similar if a new pseudoheader makes trouble, no need for a DATA probe to upset things that don't understand. Things that didn't understand and think they are getting a normal h2 stream will either kill the stream on the, to them, illegal method, or if not will kill the stream on the first DATA anyway because --> The spec still needs to touch on the changes it is making to h2 DATA frames, it assumes it is inheriting generic bidirectional transport from h2, but it isn't. H2 DATA kills the stream if it comes outside of whatever was told for content-length: on both sides, and eg h2spec requires you to enforce that. So the spec requires changes in DATA handling implementation for upgraded streams and should note it. It should probably note there is no relationship between H2 DATA frames and the tunneled content, and that the DATA frames may be refragmented. It wouldn't hurt to notice that WINDOW_UPDATE is still required / applies. -Andy From nobody Thu Oct 26 22:01:35 2017 Return-Path: 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 072661389BC for ; Thu, 26 Oct 2017 22:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 QNcQuMddRzty for ; Thu, 26 Oct 2017 22:01:28 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 3BBA2139438 for ; Thu, 26 Oct 2017 22:01:28 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id g125so9176264oib.12 for ; Thu, 26 Oct 2017 22:01:28 -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=CPIcBVdbms9Tyjl7LA/FVLfcwGCClTD+8zyL1oOcKrQ=; b=pe6o9v531yh6TLAjcOY8/EixYWwytT0wLy9PbezqMuEUf3DGZ8N9wBa+Udr4RsERrL dTfCOtFd5AQ4e0yjDcP2fjW0jZeNGE2NdQttWWwlKlHeGfPbVuR1vMDVTOYUlMXlGaSe ANRHyaPwgb9tXcXW6YuzDnm0Z6ugmMDRTCMSr5ZQu/kOeYhK7eUr3QRkLt87W8Lv3aVZ Ps5DrIqVrI1JnIspe32v7UMCljuS66SJUsD/P7z/7fvne6Kf6r2vS8VofJo1ncedf6Wy egPtbQrSzo8HqJwG8aCKk/1jxIcIFTx6z/r3+Xj/VeEwyGNqM+Hx+kJuam64w8vokfgY gdBg== 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=CPIcBVdbms9Tyjl7LA/FVLfcwGCClTD+8zyL1oOcKrQ=; b=g2D4TKj19RhTR3+ptSFDYtEQj/lLfZFTWEtqCFuljUZFdsDK1ACN8hG+nkydRWcWtY x9t+wE7kjRI5EMWCwdu63GVAGT2QSc5OK3/GhZaGUmqTEXEn4dntuvDw5c0qRALCw5lm 4QvK1stsBOxV6akAKx9TI3tFBPfLe4LUA//50j3mx24mg8/MN5AdxwbIEUAaJE2OzRdg Atc+mE2+UVbaznNq+1AATXkPFbbCvR7sIs/sN6W5p/oqOzJgo3YdgGuY/rG3jH6Wm0k2 gMdFWC18WkvtrFxvDFtrj1d3wY5xNnzRUc+n4l5fn89BqhzSToNXmIGb/VWLPF+QS8yD FP1w== X-Gm-Message-State: AMCzsaWURn3rjg6HgbFaj2giQrYwKNWoJcECQ0Ld4zAkl7X7qcUphDSi yUpqwLXVFBoSd9h7liR4vWRU3fWX+MTln2YpdMjRaw== X-Google-Smtp-Source: ABhQp+Q3F712wYrKf8fVtSYNfuQiIdbB3luXqsu7CWxc3LoOSQJ7nlqGmB2zZY9zb2nJZ3RwKIQYJf7p6MX8f1asD7o= X-Received: by 10.202.213.209 with SMTP id m200mr3375022oig.177.1509080487595; Thu, 26 Oct 2017 22:01:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 26 Oct 2017 22:01:27 -0700 (PDT) In-Reply-To: <76309743-EB28-4B47-BB94-254421538582@mnot.net> References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> <76309743-EB28-4B47-BB94-254421538582@mnot.net> From: Martin Thomson Date: Fri, 27 Oct 2017 16:01:27 +1100 Message-ID: To: Mark Nottingham Cc: John Fallows , Patrick McManus , hybi , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 05:01:34 -0000 On Fri, Oct 27, 2017 at 10:39 AM, Mark Nottingham wrote: > Just to give some context as to why I don't think it's a subtle change -- consider OWASP's mod_security CRS, which is the basis of most WAF products. It has baked-in assumptions about the semantics of CONNECT; e.g., > I found this message quite obtuse (and that file worse), but what I think you are saying is that an origin server might treat CONNECT specially in a way that might make a new method easier to deploy. That's a fine argument for a new method. From nobody Thu Oct 26 22:03:14 2017 Return-Path: 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 A9B14139438 for ; Thu, 26 Oct 2017 22:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=T99uAw2/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YIHNKUHD 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 wwGM657RsIu2 for ; Thu, 26 Oct 2017 22:03:11 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C1E1389BC for ; Thu, 26 Oct 2017 22:03:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 397B220D0A; Fri, 27 Oct 2017 01:03:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 27 Oct 2017 01:03:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=hEOtUf/tCfog9ukyaaVuxowj6xZEl p+d11s7z9EqBdI=; b=T99uAw2/BUM1c/vYW3va5IVjuqqAKd8UZmUm0FaXvionE YnB1UnTm54uIWnio+JhIqbZ8FpBgICHwP7bWVFEb6c2zVNHvVfKwcb4kqJRQTaGu kFFNIejq3jYRKwOZ97Lp1FgwtCWO3gYUY4GuhJGG5EJqdiHTpuk2K4S1PkNj2qaT BrbDjhoffnHooLeFfmtTyRywxZtGsvJCQ4WZbc0626UrVsBAW/AW8RzyCciagd79 rxkLFTec0iyN9Ti1JYxzAm3ReFrBN1Gw++qKC248+x93q14PN5oGob3FSwrmwrpl lAJfhR6G5MrYzH0Valh9HWIu4ZYfNi7V4aVGvIAUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hEOtUf /tCfog9ukyaaVuxowj6xZElp+d11s7z9EqBdI=; b=YIHNKUHD47EOemqBrQGFyx sONrNl78cdwTCYSIxkvbqPYTUWtFu8VLPIK0t8TLZ6WVNO3+wmH8/NzCzW3QzV6x Cg+DRjiaXnitqlUtkuF0dfUWKDlotcB6+mcSzYVqIwgb0+CnKVzTBaLa2uqlmU52 vekVXCvLXDBXYEGS61zLCoR0VaebMe9l02vmrc7ckk8mMWeMJmHk/FDqn960eEnb 3TiC4CoU1uPf9tQd9NmGHjmCWtJMxBRe6ztLyJigBUwmPqCiUMbGQxcaiNA+ktEt RrqNW2daqJnnXx+ehSYP2kQT5QvjYaU7V+gl/ZLyOgDxNhumDSZD1pjOOUMm3v1w == X-ME-Sender: Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 9261724536; Fri, 27 Oct 2017 01:03:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: Date: Fri, 27 Oct 2017 16:03:04 +1100 Cc: John Fallows , Patrick McManus , hybi , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> <76309743-EB28-4B47-BB94-254421538582@mnot.net> To: Martin Thomson X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [hybi] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 05:03:13 -0000 On 27 Oct 2017, at 4:01 pm, Martin Thomson = wrote: >=20 > On Fri, Oct 27, 2017 at 10:39 AM, Mark Nottingham = wrote: >> Just to give some context as to why I don't think it's a subtle = change -- consider OWASP's mod_security CRS, which is the basis of most = WAF products. It has baked-in assumptions about the semantics of = CONNECT; e.g., >> = >=20 > I found this message quite obtuse (and that file worse), but what I > think you are saying is that an origin server might treat CONNECT > specially in a way that might make a new method easier to deploy. > That's a fine argument for a new method. We work in a field of jargon and extreme specialisation. You should try = talking to those browser folks sometime... -- Mark Nottingham https://www.mnot.net/ From nobody Thu Oct 26 23:59:59 2017 Return-Path: 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 D87DC13B126 for ; Thu, 26 Oct 2017 23:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 3KVE_De7i6t8 for ; Thu, 26 Oct 2017 23:59:56 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8D26E139203 for ; Thu, 26 Oct 2017 23:59:54 -0700 (PDT) Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id C1E4066009E; Fri, 27 Oct 2017 19:59:51 +1300 (NZDT) To: Andy Green , John Fallows , Patrick McManus Cc: hybi , HTTP Working Group References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Amos Jeffries Message-ID: <1e9970aa-d0ef-6887-bd27-6ec344a80bc1@treenet.co.nz> Date: Fri, 27 Oct 2017 19:59:51 +1300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 06:59:58 -0000 On 27/10/17 12:40, Andy Green wrote:> > The spec still needs to touch on the changes it is making to h2 DATA > frames, it assumes it is inheriting generic bidirectional transport from > h2, but it isn't.  H2 DATA kills the stream if it comes outside of > whatever was told for content-length: on both sides, and eg h2spec > requires you to enforce that.  So the spec requires changes in DATA > handling implementation for upgraded streams and should note it. AIUI, Content-Length remains optional in h2 as it was in 1.x. The h2 equivalent of Transfer-Encoding:chunked is being used by wss. Just a stream of DATA frames in both directions terminated by the END_STREAM flag instead of a specific Content-Length value. Amos From nobody Fri Oct 27 00:33:18 2017 Return-Path: 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 D7E0013F486 for ; Fri, 27 Oct 2017 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Ab9NLVUyizgT for ; Fri, 27 Oct 2017 00:33:15 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867BF139203 for ; Fri, 27 Oct 2017 00:33:15 -0700 (PDT) To: Amos Jeffries , John Fallows , Patrick McManus Cc: hybi , HTTP Working Group References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> <1e9970aa-d0ef-6887-bd27-6ec344a80bc1@treenet.co.nz> From: Andy Green Message-ID: Date: Fri, 27 Oct 2017 15:32:05 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 In-Reply-To: <1e9970aa-d0ef-6887-bd27-6ec344a80bc1@treenet.co.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 07:33:17 -0000 On 10/27/2017 02:59 PM, Amos Jeffries wrote: > On 27/10/17 12:40, Andy Green wrote:> >> The spec still needs to touch on the changes it is making to h2 DATA >> frames, it assumes it is inheriting generic bidirectional transport >> from h2, but it isn't.  H2 DATA kills the stream if it comes outside >> of whatever was told for content-length: on both sides, and eg h2spec >> requires you to enforce that.  So the spec requires changes in DATA >> handling implementation for upgraded streams and should note it. > > AIUI, Content-Length remains optional in h2 as it was in 1.x. The h2 h2spec tests for these 8.1.2.6. Malformed Requests and Responses ✔ 1: Sends a HEADERS frame with the "content-length" header field which does not equal the DATA frame payload length ✔ 2: Sends a HEADERS frame with the "content-length" header field which does not equal the sum of the multiple DATA frames payload length > equivalent of Transfer-Encoding:chunked is being used by wss. Just a > stream of DATA frames in both directions terminated by the END_STREAM > flag instead of a specific Content-Length value. Well, that is banned in h2, but I guess you are right, if there is no content-length: it can just end on END_STREAM and there's no problem... it's my misunderstanding I guess. -Andy > Amos > From nobody Fri Oct 27 05:33:28 2017 Return-Path: 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 84D6713AF04 for ; Fri, 27 Oct 2017 05:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 sRW5WL99BJ2o for ; Fri, 27 Oct 2017 05:33:24 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6C13A8A1 for ; Fri, 27 Oct 2017 05:33:24 -0700 (PDT) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id AD5253A0A2 for ; Fri, 27 Oct 2017 08:33:23 -0400 (EDT) Received: by mail-lf0-f45.google.com with SMTP id p184so7216312lfe.12 for ; Fri, 27 Oct 2017 05:33:23 -0700 (PDT) X-Gm-Message-State: AMCzsaV/rbgu2WJh8spe7KOk/rtZxgHfTa3Xf6p0M9U7mgieSyWLsmym ELDPVEqPAuHZVGb3o0IY9rUQQuwcPYJDM1vsx4s= X-Google-Smtp-Source: ABhQp+T7pqjo40LCp/5Sm6ZamMr6m6G7q1Oln+n5vZaarSJWPUeaxACmC2UB7L7HRDBiDZTArIk4UT0u/yvCEKtwq+k= X-Received: by 10.25.209.19 with SMTP id i19mr114450lfg.127.1509107602370; Fri, 27 Oct 2017 05:33:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Fri, 27 Oct 2017 05:33:21 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Fri, 27 Oct 2017 06:33:21 -0600 X-Gmail-Original-Message-ID: Message-ID: To: John Fallows Cc: Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="001a114122629135c6055c867e6f" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:33:27 -0000 --001a114122629135c6055c867e6f Content-Type: text/plain; charset="UTF-8" thanks for the feedback.. start with a tightly scoped issue first: On Thu, Oct 26, 2017 at 3:47 PM, John Fallows wrote: > > 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. > I don't think so.. there is no https target URL in play here. 7540 8.1.2.3 talks about non http schemes allowing the use of HTTP to interact with non-http services this way. --001a114122629135c6055c867e6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks for the feedback.. start with a tightly scoped issu= e first:

= On Thu, Oct 26, 2017 at 3:47 PM, John Fallows <john.fallows@kaazing= .com> wrote:

Note als= o that the scheme is "https" rather than "wss" because = the HTTP request is still "https" until *after* the TUNNEL has be= en established, and the TUNNEL protocol being selected is based on <= span style=3D"font-size:small">:protocol header rather t= han the :sc= heme h= eader.

I don't= think so.. there is no https target URL in play here.=C2=A0 7540 8.1.2.3 t= alks about non http schemes allowing the use of HTTP to interact with non-h= ttp services this way.

<= div dir=3D"ltr" style=3D"unicode-bidi:-webkit-isolate">

--001a114122629135c6055c867e6f-- From nobody Fri Oct 27 08:49:05 2017 Return-Path: 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 44AF713F4F1 for ; Fri, 27 Oct 2017 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no 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 8Sb7NpzJlqgB for ; Fri, 27 Oct 2017 08:49:01 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9B138BD6 for ; Fri, 27 Oct 2017 08:49:01 -0700 (PDT) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 220663A0A8 for ; Fri, 27 Oct 2017 11:49:00 -0400 (EDT) Received: by mail-lf0-f52.google.com with SMTP id r129so7879589lff.8 for ; Fri, 27 Oct 2017 08:49:00 -0700 (PDT) X-Gm-Message-State: AMCzsaU3vhINDD2Klkx2HKzHmitEB1O/P89ny3/CENNP3Ihl+eQ+5DDj 4JUdWKiAIuSoDvfNt3X7Or1fs0I8nR1cXOlCAEM= X-Google-Smtp-Source: ABhQp+QNj+TmDR4+OF7PU594PJmKGKbQSnvJxYqDzZi9LtcaWVkbSjzjqAMu8ooKr9jOsvczV3o/hoMzHxs85b4eXNY= X-Received: by 10.46.87.12 with SMTP id l12mr400096ljb.44.1509119338273; Fri, 27 Oct 2017 08:48:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Fri, 27 Oct 2017 08:48:57 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Fri, 27 Oct 2017 11:48:57 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andy Green Cc: John Fallows , Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="f403045f8c5614e242055c893a2e" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 15:49:03 -0000 --f403045f8c5614e242055c893a2e Content-Type: text/plain; charset="UTF-8" On Thu, Oct 26, 2017 at 7:40 PM, Andy Green wrote: > > > While I think the first draft, second draft or this suggestion are already > good enough and get the result of eliminating the tcp + tls setup for ws > needed today, > > The IETF - seeking consensus on how to skin a cat. --f403045f8c5614e242055c893a2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 26, 2017 at 7:40 PM, Andy Green <andy@warmcat.com> wrote:


 While I think the first draft, second draft or this suggestion are already = good enough and get the result of eliminating the tcp + tls setup for ws ne= eded today,


The IETF - seeking consensus on how t= o skin a cat.
=C2=A0

--f403045f8c5614e242055c893a2e-- From nobody Fri Oct 27 09:43:07 2017 Return-Path: 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 2E30513EF5E for ; Fri, 27 Oct 2017 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kaazing-com.20150623.gappssmtp.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 i1gl22RfbfQG for ; Fri, 27 Oct 2017 09:43:04 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 62AA01389C1 for ; Fri, 27 Oct 2017 09:43:04 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id h34so5298220uaa.6 for ; Fri, 27 Oct 2017 09:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaazing-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tV68eKPuhYkZ4vTn9BUGV0fU7b4w4DrMZp80wVd7Tx8=; b=l6RRWibazVAYXMrbnIusyq7teVRs/wdVTo42CARlFxq5DVOwFwu8aJwyFTaGFJzsDH VX4RPwGgCkiG/qGGI9QmFid85yYdWL0EC7dW94K5/U/j740qkzwqwayDkhrHsMVRRyWX LtIo7AFezHywiIj/DUtp6Zb8t8o6Fbs3P87UbvUzqvkUygyAbTAiuXe8wZaXWZAWJudZ 4ZkC1L5u7h6OYoNOH7grpEhop18qgTzIk26BG2kdmFuHIJ1FXG6dPO/ivep/h/Lr7vop 0JEBta5cG0yLcqVYuB2MnLcnioSRBeymzMt/y/RyFvSuuWWaGZTsjPtIQC+q22hgg3qT aWdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tV68eKPuhYkZ4vTn9BUGV0fU7b4w4DrMZp80wVd7Tx8=; b=H1J0wbgUUU0Ntz0932+HJLLK9ZcHP/LSULLSO/9GpYHC/w+04uWsFRKasgvLw7i640 U/YU2aSgpBEZU4TGyJgu9Enbj/mCHitBRZtPXHozfshHqe01XnvIxizfS+akL0arUUMm EvPEGAoqr+cjIft/7nG54Q4DTZ6sZBtzkVECXkf/aB4xsGLjpwApH2Zs7vTyV1n5Lf09 8k995iUyoEmrhnzhz3cFo7D4b84CQaZ63g/3rybnJEZJUmCIsQXyePO0JX/BnD1DYK0F gv8b1gJayH4ncI7KSO70VS9xYMkFrw6kYCdaZYsrqS5wpnPnI6Dd5IyjUooW9sc69bsv VoEg== X-Gm-Message-State: AMCzsaVGtioxBXbTNQFW/+Uj9pCZUuvwx4m5OYVAR29BARvoyLuR7J+3 zZ8JCd3q3l1tSmBzcUuWNW6jhGr1Z07VFFhHkuxsmw== X-Google-Smtp-Source: ABhQp+QK47oTkXip/8waxMa+GynsAuL29R1Bluvr/ZSkPrFzekWA6/um9+C1imiiS/L2LBbuRwVc9Q0NgHn7z9qXTgs= X-Received: by 10.176.91.75 with SMTP id v11mr1048587uae.26.1509122583293; Fri, 27 Oct 2017 09:43:03 -0700 (PDT) MIME-Version: 1.0 References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> In-Reply-To: From: John Fallows Date: Fri, 27 Oct 2017 16:42:52 +0000 Message-ID: To: Patrick McManus Cc: hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="f403045f896a80077d055c89fbd7" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:43:06 -0000 --f403045f896a80077d055c89fbd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Patrick, There seems to be no requirement to change the scheme to wss for a functional handshake using TUNNEL method plus :protocol header with value websocket. In the example, the target URL used by the WebSocket on the wire would be https://server.example.com/chat. The cross-origin security checks (etc) are enforced by HTTP-specific validation of the request headers prior to processing the TUNNEL method semantics. If the validation fails, then the request never became a WebSocket. Only after a successful HTTP response is provided can the pair of HTTP/2 streams be considered a WebSocket. In the earliest days of the WebSocket protocol design, there was strong emphasis on using a constrained form of HTTP/1.1 to describe the WebSocket handshake, which in part contributed to creation of the schemes "ws" and "wss" because it wasn't really HTTP per se. Even after this was cleaned up to be a fully HTTP/1.1 compliant handshake, as part of the work in IETF HyBi, the "ws" and "wss" schemes remained in use on the client (only) but were deliberately not exposed on the wire. Having separate schemes for protocols that must start out life as HTTP forces questions about port defaulting for those schemes. Since the "ws" and "wss" schemes ended up being treated the same as "http" and "https" in terms of port defaulting, there doesn't seem to be much value in propagating the "wss" scheme to the server especially when the :protocol header is present with value "websocket". Hope this is helpful. Kind Regards, John Fallows CTO, Kaazing On Fri, Oct 27, 2017 at 5:33 AM Patrick McManus wrote: > thanks for the feedback.. start with a tightly scoped issue first: > > On Thu, Oct 26, 2017 at 3:47 PM, John Fallows > wrote: > >> >> 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. >> > > I don't think so.. there is no https target URL in play here. 7540 > 8.1.2.3 talks about non http schemes allowing the use of HTTP to interact > with non-http services this way. > > > -- *John Fallows* CTO* | *=F0=9F=93=9E+1.415.215.6597 *----------------------------------------------------------------------* KAAZING >|< when real-time matters=E2=84=A2 kaazing.com/kwic | Blog | Twitter --f403045f896a80077d055c89fbd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Patrick,

There seems to be no requir= ement to change the scheme to wss for a fun= ctional handshake using TUNNEL method plus = :protocol header with value websocket.

In the example, the ta= rget URL used by the WebSocket on the wire would be https://server.example.com/ch= at. The cross-origin security checks (etc) are enforced by HTTP-= specific validation of the request headers prior to processing the TUNNEL method semantics. If the validation fails, t= hen the request never became a WebSocket. Only after a successful HTTP resp= onse is provided can the pair of HTTP/2 streams be considered a WebSocket.<= /div>

In the earliest days of the WebSocket protocol des= ign, there was strong emphasis on using a constrained form of HTTP/1.1 to d= escribe the WebSocket handshake, which in part contributed to creation of t= he schemes "ws" and "wss" because it wasn't really = HTTP per se.

Even after this was cleaned up to be = a fully HTTP/1.1 compliant handshake, as part of the work in IETF HyBi, the= "ws" and "wss" schemes remained in use on the client (= only) but were deliberately not exposed on the wire.

Having separate schemes for protocols that must start out life as HTTP f= orces questions about port defaulting for those schemes. Since the "ws= " and "wss" schemes ended up being treated the same as "= ;http" and "https" in terms of port defaulting, there doesn&= #39;t seem to be much value in propagating the "wss" scheme to th= e server especially when the :protocol header is present with value "w= ebsocket".

Hope this is helpful.
Kind Regards,
John Fallows
CTO, Kaazing

On Fri, Oct 27, 20= 17 at 5:33 AM Patrick McManus <p= mcmanus@mozilla.com> wrote:
=
thanks for the feedback.. start with a tightly scoped issu= e first:

=
On Thu, Oct 26, 2017 at 3:47 PM, John Fallows <john.fallows@kaazing.com> wrote:

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 sele= cted is based on :protocol header rather than the :scheme header.
<= br>
I don't think so.. there is no h= ttps target URL in play here.=C2=A0 7540 8.1.2.3 talks about non http schem= es allowing the use of HTTP to interact with non-http services this way.


--
John Fallows
CTO=C2=A0 | =C2=A0=F0=9F=93=9E+1.415.215.6597
----------------------------------------------------------------------=
KAAZING= =C2=A0>|= <=C2=A0=C2=A0when rea= l-time matters=E2=84=A2
kaazing.com/k= wic=C2=A0= =C2=A0| =C2=A0Blog=C2=A0=C2=A0| =C2=A0Twitter=C2=A0=
<= /div>
=
--f403045f896a80077d055c89fbd7-- From nobody Fri Oct 27 10:14:07 2017 Return-Path: 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 8DBCB138A38 for ; Fri, 27 Oct 2017 10:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 TF7HhmdckBsN for ; Fri, 27 Oct 2017 10:14:03 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 33D7C1384B5 for ; Fri, 27 Oct 2017 10:14:03 -0700 (PDT) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 390B93A01B for ; Fri, 27 Oct 2017 13:14:02 -0400 (EDT) Received: by mail-lf0-f46.google.com with SMTP id n69so8149667lfn.2 for ; Fri, 27 Oct 2017 10:14:02 -0700 (PDT) X-Gm-Message-State: AMCzsaXLej9EGv+kc1HKrpNka4bxtYd/YJl9dLnKIvdBj/+TJMdbVAtK 5Y7S7c/sG/LDjqWSXRmjQ6/UAQi+E6jAwUTdic0= X-Google-Smtp-Source: ABhQp+R61gA3zY1TX7wOoypx6ViEkTtRyN0C3cJ9E07GlCfFSdnYgBmMFIMxYAAZRwwuUE3VD42OGS3eWeVXG+2QSxw= X-Received: by 10.46.87.12 with SMTP id l12mr493763ljb.44.1509124440821; Fri, 27 Oct 2017 10:14:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Fri, 27 Oct 2017 10:13:59 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Fri, 27 Oct 2017 13:13:59 -0400 X-Gmail-Original-Message-ID: Message-ID: To: John Fallows Cc: Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="f403045f8c5637970e055c8a6ab6" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:14:05 -0000 --f403045f8c5637970e055c8a6ab6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 27, 2017 at 12:42 PM, John Fallows wrote: > Hi Patrick, > > There seems to be no requirement to change the scheme to wss for a > functional handshake using TUNNEL method plus :protocol header with value > websocket. > I'm not changing the scheme. It was also wss in http/1.1 as well - its just that scheme does not typically appear on the wire in that protocol. My reference to 7540 8.1.2.3 explicitly talks about non http schemes (ftp is the most common). That doesn't make CONNECT/TUNNEL non http.. it just means http is being used to interact with a non-http service.. > > In the example, the target URL used by the WebSocket on the wire would be > https://server.example.com/chat. > no.. the target url is wss://server.example.com/chat and this is a definition of how to use h2 to access that service. This document doesn't say anything about how to access an https:// schemed url. If the URL were https://server.example.com it would be rejected by a websocket client which requires ws or wss. PAC evaluation also expects ws/wss schemes. > The cross-origin security checks (etc) are enforced by HTTP-specific > validation of the request headers prior to processing the TUNNEL method > semantics. If the validation fails, then the request never became a > WebSocket. Only after a successful HTTP response is provided can the pair > of HTTP/2 streams be considered a WebSocket. > maybe you're confusing protocol with scheme? > > Even after this was cleaned up to be a fully HTTP/1.1 compliant handshake= , > as part of the work in IETF HyBi, the "ws" and "wss" schemes remained in > use on the client (only) but were deliberately not exposed on the wire. > whether or not the scheme is on the wire is a property of http - not something hybi was ever in a position to standardize. (thus the 'cleanup'.) one weird note of 7230 5.3.2 requires that servers MUST accept absolute form requests even though clients are forbidden from sending them to non-proxies. The absolute form here would be wss://.. so this is an h1 thing too it just wasn't obvious. > > Having separate schemes for protocols that must start out life as HTTP > forces questions about port defaulting for those schemes. Since the "ws" > and "wss" schemes ended up being treated the same as "http" and "https" i= n > terms of port defaulting, there doesn't seem to be much value in > propagating the "wss" scheme to the server especially when the :protocol > header is present with value "websocket". > you can of course imagine :protocol changing to be websocket2 with the scheme not changing. > > Hope this is helpful. > > Kind Regards, > John Fallows > CTO, Kaazing > > On Fri, Oct 27, 2017 at 5:33 AM Patrick McManus > wrote: > >> thanks for the feedback.. start with a tightly scoped issue first: >> >> On Thu, Oct 26, 2017 at 3:47 PM, John Fallows >> wrote: >> >>> >>> 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. >>> >> >> I don't think so.. there is no https target URL in play here. 7540 >> 8.1.2.3 talks about non http schemes allowing the use of HTTP to interac= t >> with non-http services this way. >> >> >> -- > *John Fallows* > CTO* | *=F0=9F=93=9E+1.415.215.6597 > *----------------------------------------------------------------------* > KAAZING >|< when real-time matters=E2=84=A2 > kaazing.com/kwic | Blog > | Twitter > --f403045f8c5637970e055c8a6ab6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 27, 2017 at 12:42 PM, John Fallows <john.fallows@ka= azing.com> wrote:
Hi Patrick,

There seems to be no requirement to= change the scheme to wss for a functional = handshake using TUNNEL method plus :protocol header with value websocket.

I'm not= changing the scheme. It was also wss in http/1.1 as well - its just that s= cheme does not typically appear on the wire in that protocol. My reference = to 7540 8.1.2.3 explicitly talks about non http schemes (ftp is the most co= mmon). That doesn't make CONNECT/TUNNEL non http.. it just means http i= s being used to interact with a non-http service..

=
=C2=A0

<= /div>
In the example, the target URL used by the WebSocket on the wire = would be https://server.example.com/chat.

no.. the target url is wss://server.example.com/chat and this i= s a definition of how to use h2 to access that service. This document doesn= 't say anything about how to access an https:// schemed url. If the URL= were https://server.example.com= it would be rejected by a websocket client which requires ws or wss. PAC e= valuation also expects ws/wss schemes.

=C2=A0<= /div>
The cross-origin = security checks (etc) are enforced by HTTP-specific validation of the reque= st headers prior to processing the TUNNEL m= ethod semantics. If the validation fails, then the request never became a W= ebSocket. Only after a successful HTTP response is provided can the pair of= HTTP/2 streams be considered a WebSocket.

maybe you're confusing protocol with scheme?=
=C2=A0

Even after this was cleaned up to be a fully HTTP/1.1 complian= t handshake, as part of the work in IETF HyBi, the "ws" and "= ;wss" schemes remained in use on the client (only) but were deliberate= ly not exposed on the wire.

whe= ther or not the scheme is on the wire is a property of http - not something= hybi was ever in a position to standardize. (thus the 'cleanup'.)<= /div>

one weird note of 7230 5.3.2 requires that servers= MUST accept absolute form requests even though clients are forbidden from = sending them to non-proxies. The absolute form here would be wss://.. so th= is is an h1 thing too it just wasn't obvious.

<= div>=C2=A0

Having separate schemes for protocols that must start out life as = HTTP forces questions about port defaulting for those schemes. Since the &q= uot;ws" and "wss" schemes ended up being treated the same as= "http" and "https" in terms of port defaulting, there = doesn't seem to be much value in propagating the "wss" scheme= to the server especially when the :protocol header is present with value &= quot;websocket".


you can of course imagine :protocol changing to be websocket2 with th= e scheme not changing.

=C2=A0

Hope this is helpful.<= /div>

Kind Regards,
John Fall= ows
CTO, Kaazing

On Fri, Oct 27, 2= 017 at 5:33 AM Patrick McManus <pmcmanus@mozilla.com> wrote:
thanks for the feedback.. start with a = tightly scoped issue first:

On Thu, Oct 26, 2017 at 3:47 PM= , John Fallows <john.fallows@kaazing.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Note also that the scheme is "http= s" 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.

I don't thi= nk so.. there is no https target URL in play here.=C2=A0 7540 8.1.2.3 talks= about non http schemes allowing the use of HTTP to interact with non-http = services this way.

= <= div class=3D"m_-6414824608760271515m_-2107626842083120614m_-664023251148404= 6871inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33);font-family:'helve= tica neue',helvetica,arial,sans-serif;font-size:13px;font-style:normal;= font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:19= .5px;text-align:start;text-indent:0px;text-transform:none;white-space:norma= l;word-spacing:0px;background-color:rgb(255,255,255)">
=

--
= John Fallows
CTO=C2=A0 | =C2=A0=F0=9F=93=9E+1.415.215.6597
-------------------------------------------------------------= ---------
KAAZING=C2=A0>|<=C2=A0=C2=A0= when real-time matters=E2=84=A2
kaazing.com/kwic=C2=A0=C2=A0| =C2=A0Blog=C2=A0=C2=A0| =C2=A0= Twitter=C2=A0
=

--f403045f8c5637970e055c8a6ab6-- From nobody Fri Oct 27 10:25:17 2017 Return-Path: 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 A624013AD2D for ; Fri, 27 Oct 2017 10:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 87Ni6euNEtCq for ; Fri, 27 Oct 2017 10:25:15 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 77188139059 for ; Fri, 27 Oct 2017 10:25:15 -0700 (PDT) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id E8EDC3A01B for ; Fri, 27 Oct 2017 13:25:14 -0400 (EDT) Received: by mail-lf0-f41.google.com with SMTP id w21so8194220lfc.6 for ; Fri, 27 Oct 2017 10:25:14 -0700 (PDT) X-Gm-Message-State: AMCzsaW8m6bfR0PK5zZpmt+q498RCcFvg7yxne+eWuTwO8bGQpuIJnXg fSNjfWG3gw+u0b9CJTYDTyK+6GzlD9sDcdoFrH0= X-Google-Smtp-Source: ABhQp+SBU30JFv2PmIOdSTzOGMKz8C9DFOSTQLoCEAlyKoyMu81rJ2OPrOy5EjxxwjSmk6sB6zKXX8WeiCON5H6hO54= X-Received: by 10.46.67.201 with SMTP id z70mr579831lje.124.1509125113524; Fri, 27 Oct 2017 10:25:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Fri, 27 Oct 2017 10:25:12 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Fri, 27 Oct 2017 13:25:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: John Fallows , Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="94eb2c1ab5065039eb055c8a92d8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:25:17 -0000 --94eb2c1ab5065039eb055c8a92d8 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 26, 2017 at 7:07 PM, Martin Thomson wrote: > > > One thing that using :protocol suggests to me is that we need a new status > code for thi > the existing, inherited, CONNECT rule is that 2xx means OK and anything else means no tunnel. Is defining something better than 501 going to help the client do something useful? s, just in case someone asks for an unsupported protocol. And you probably > want a registry for :protocol values (yay). > > ha! So I actually re-used the existing Upgrade registry for this. Was that too rude? I also coming around to naming the pseudo-header :upgrade for simplicity sake even though its not a great descriptor without a lot of context. --94eb2c1ab5065039eb055c8a92d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 26, 2017 at 7:07 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:


One thing that using :protocol suggests to= me is that we need a new status code for thi
=
the existing, inherited, CONNECT rule is that 2xx means OK a= nd anything else means no tunnel. Is defining something better than 501 goi= ng to help the client do something useful?

s, just in case someone asks f= or an unsupported protocol.=C2=A0 And you probably want a registry for :pro= tocol values (yay).


ha! So I actually re-used the existing Upgrade registry for this. W= as that too rude? I also coming around to naming the pseudo-header :upgrade= for simplicity sake even though its not a great descriptor without a lot o= f context.

=C2=A0
--94eb2c1ab5065039eb055c8a92d8-- From nobody Sat Oct 28 02:44:54 2017 Return-Path: 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 7C5E413AB34 for ; Sat, 28 Oct 2017 02:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kaazing-com.20150623.gappssmtp.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 21NT9UEvFpVe for ; Sat, 28 Oct 2017 02:44:50 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 D97B313A214 for ; Sat, 28 Oct 2017 02:44:49 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id v27so6461502uav.7 for ; Sat, 28 Oct 2017 02:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaazing-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ekmRJhMDJt9XSWSy+XIz5CeVmE/Zx1SQpVhCHJJPiIk=; b=aEcNiUrZdKMSjM0cfvBpm5LLR+xth6Q/+rd9HHjkax/OjHvoox9Nnqy4JYCLcldEqJ WGCu3w+F33Tp58o4EVzn2EN5Eoq1p3R0E8wzMyNVg/EHuZixgZTr2X8dXcHB1mIhpCBl JrPnXdfT0rwHZFtfmKpaN8e052foE8LeU3dXfdWx95pVGp5vLgsbdt6tNwCPP6/oez5P hObgUm03EA8i75EoymGEnrU6Oe+NwK4yWk6Dapng/bUNmHaZ7McpA/o4T3daara+KiJb l36mfDS/cdKdNhIr4jS77/nic+kO4snK0O+IuAN+bkruD+G/GAGb8pXAiajQqNNzLshY 3FeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ekmRJhMDJt9XSWSy+XIz5CeVmE/Zx1SQpVhCHJJPiIk=; b=gaJz2VfoMijwlo1iHnuk0k+toOj597ns9hsaiPWzBlp5KQMaYxoGUoicgTsYKLnsQ9 DcgcHcP237rHNDBplSOTOoXgotU2khwyLsWa+PumpoMz5FSvVR85PgbopYzM+eOc3fcJ Tk/we9WH2q+CwTQl783ZgOjZLmjpVsCtZmGZteG2dFqTYu1poctSYflF4gThLCZi4d+W FxMeuj9seCP03fU2m9Es9S0EpWPRcVigLygr+mjB8yZJavxMIAxAIjqvGU/0YlFYz8oG njo+LyQBV6U5gYmZ4HaFeW06gCW5Yq9IKju5vuX8mTp0dwQs6QKKkmKWFE/+S0T0LzzE kIIg== X-Gm-Message-State: AMCzsaUDKp1AlKOZAJ7N8Xu7mcmZepnMasCua7/yQLYauG6VyE/uPW7E cD3L/2DTEfEBnNojNaWKL9tEmpRfc7POfIOt9+bPodKf X-Google-Smtp-Source: ABhQp+RiQlCiy7OvJZG6qRyKdjS8Kgfu50abxsv/wDZqDXRwHEcd2rqjmwUi52hJy0gNTlGw08uyJCqT1ENG801H/MQ= X-Received: by 10.176.64.131 with SMTP id i3mr2872909uad.195.1509183888685; Sat, 28 Oct 2017 02:44:48 -0700 (PDT) MIME-Version: 1.0 References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> In-Reply-To: From: John Fallows Date: Sat, 28 Oct 2017 09:44:37 +0000 Message-ID: To: Patrick McManus Cc: hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="94eb2c12370e961242055c984189" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 09:44:52 -0000 --94eb2c12370e961242055c984189 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Patrick, Thanks for taking the time to address my feedback - comments inline below. :-) On Fri, Oct 27, 2017 at 10:14 AM Patrick McManus wrote: > On Fri, Oct 27, 2017 at 12:42 PM, John Fallows > wrote: > >> Hi Patrick, >> >> There seems to be no requirement to change the scheme to wss for a >> functional handshake using TUNNEL method plus :protocol header with >> value websocket. >> > > I'm not changing the scheme. It was also wss in http/1.1 as well - its > just that scheme does not typically appear on the wire in that protocol. > This one is subtle. Imagine if the client JavaScript API had elected to use: new WebSocket("https://example.com/chat", ["chat", "superchat"]) instead of: new WebSocket("wss://example.com/chat ", ["chat", "superchat"]) then absolutely nothing about the wire protocol would have needed to change for HTTP/1.1 WebSocket. Interestingly, one of the original WebSocket handshake response headers called WebSocket-Location, with ws[s] scheme URL, was removed as part of the cleanup to use HTTP/1.1 proper. As mentioned, the invention of the ws and wss schemes were born from not using HTTP/1.1 proper from the beginning, including initially having non-HTTP default ports such as 81 for ws instead of 80. Server-Sent Events protocol deems it sufficient to offer a GET method with accept =3D text/event-stream header in the HTTP request, just as WebSocket protoco= l deems it sufficient (in this proposed feedback) to offer a TUNNEL method with :protocol =3D websocket pseudo-header in the HTTP request. Although the origins of the WebSocket protocol design initially diverged from HTTP, after the convergence on HTTP/1.1 proper, there was no remaining justification for the "ws" and "wss" schemes from a network protocol perspective, so they became a client-side concept enforced by the WebSocket API and used by Proxy Auto-Configuration (PAC). I'm suggesting we keep the "wss" scheme as a client-side concept, but also avoid propagating it into the HTTP/2 network layer unnecessarily. Including it just forces the server to pretend the :scheme =3D https anyway, e.g. the server needs to know about :scheme =3D wss explicitly to treat it as https while still processing HTTP layer semantics, such as cross-origin security. >From an abstraction layering point of view, only WebSocket should depend on HTTP, not the reverse. My reference to 7540 8.1.2.3 explicitly talks about non http schemes (ftp > is the most common). That doesn't make CONNECT/TUNNEL non http.. it just > means http is being used to interact with a non-http service.. > Good point - I went back and re-read RFC 7540, section 8.1.2.3 regarding the :scheme pseudo-header (copied below). *:scheme is not restricted to http and https schemed URIs. A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services.* I understood this to mean that an HTTP GET request with scheme ftp could be translated by an HTTP/2 proxy or gateway to a certain usage of FTP wire protocol, such as file retrieval, while an HTTP POST request with scheme ftp might be translated as file upload via FTP wire protocol. That desired translation of HTTP <=3D> FTP is captured by the :scheme =3D f= tp pseudo-header. Since we are not trying to translate between HTTP primitives and WebSocket protocol primitives, the use of :scheme =3D wss doesn't seem quite right. > In the example, the target URL used by the WebSocket on the wire would be >> https://server.example.com/chat. >> > > no.. the target url is wss://server.example.com/chat and this is a > definition of how to use h2 to access that service. This document doesn't > say anything about how to access an https:// schemed url. If the URL were > https://server.example.com it would be rejected by a websocket client > which requires ws or wss. PAC evaluation also expects ws/wss schemes. > I think you missed my point - sorry, my fault. I was trying to draw a clear distinction between a particular WebSocket client implementation requirement (W3C territory) and the WebSocket protocol requirement (IETF territory). >From a network protocol perspective, all HTTP requests aimed at a particular origin server, whether they use GET method or the proposed TUNNE= L method, would seem to logically have the same http or https scheme. Singling out TUNNEL method with :protocol =3D websocket to present a different :scheme =3D wss just seems to introduce more questions due to the divergence from :scheme =3D https from the network protocol perspective. Unlike a protocol, which represents a single layer in a protocol stack, a scheme often unpacks to multiple protocol layers forming a protocol stack. For example, the https scheme unpacks to http over tls over tcp. In HTTP/2, transmitting :scheme =3D https describes the protocol stack up t= o and including HTTP/2 itself. For example, this makes it easier for the server to construct URLs that can be passed back to the client, where they can be unpacked into a protocol stack consistent with the original HTTP/2 request. If the server is processing the TUNNEL method with :protocol =3D websocket = HTTP/2 request, and :scheme =3D wss is included, it is not accurately representing the protocol stack up to and including HTTP/2, because the WebSocket protocol handshake has not yet completed. Say, at the HTTP/2 layer of the protocol stack, the server wants to issue a 302 redirect to path /chat2 in absolute form. It might most naturally construct the redirect location using a consistent :scheme, :authority and in this case replacement :path. However, with :scheme =3D wss the construct= ed location would not be correctly formed as it would be requesting an HTTP redirect to wss://example.com/chat2. Instead the HTTP/2 layer at the server would need to know to pretend :schem= e =3D wss was really :scheme =3D https so it could send the redirect to https://example.com/chat2 as intended. Then the client HTTP/2 layer would need to somehow infer that the redirected request should send :scheme =3D wss even though the redirect URL had scheme https. Alternatively, the HTTP/2 layer at the server would actually send the redirect to wss://example.com/chat2, and then expect the HTTP/2 layer at the client to understand how to follow that redirect as if https and presumably include :scheme =3D wss. Putting :scheme =3D wss on the wire forces a tight coupling between the HTTP/2 and WebSocket subsystems for non-obvious benefit, while the tight coupling can be avoided by putting :scheme =3D https on the wire instead. > >> The cross-origin security checks (etc) are enforced by HTTP-specific >> validation of the request headers prior to processing the TUNNEL method >> semantics. If the validation fails, then the request never became a >> WebSocket. Only after a successful HTTP response is provided can the pai= r >> of HTTP/2 streams be considered a WebSocket. >> > > > maybe you're confusing protocol with scheme? > No, they are quite distinct as described above. The problem with sending :scheme =3D wss at the HTTP layer is that it represents a promise of what will happen after the HTTP layer instead of the current state up to and including the HTTP layer. That promise of what's to come is already captured by the :protocol =3D websocket pseudo-he= ader so :scheme =3D wss doesn't appear to be adding much value. Even after this was cleaned up to be a fully HTTP/1.1 compliant handshake, >> as part of the work in IETF HyBi, the "ws" and "wss" schemes remained in >> use on the client (only) but were deliberately not exposed on the wire. >> > > whether or not the scheme is on the wire is a property of http - not > something hybi was ever in a position to standardize. (thus the 'cleanup'= .) > > one weird note of 7230 5.3.2 requires that servers MUST accept absolute > form requests even though clients are forbidden from sending them to > non-proxies. The absolute form here would be wss://.. so this is an h1 > thing too it just wasn't obvious. > That interpretation doesn't seem consistent with RFC-6455, section 4.1 regarding absolute form (copied below). *The "Request-URI" part of the request MUST match the /resource* * name/ defined in Section 3 (a relative URI) or be an absolute* * http/https URI that, when parsed, has a /resource name/, /host/,* * and /port/ that match the corresponding ws/wss URI.* WebSocket servers should accept https://... as absolute form (not wss://...), then process the Upgrade: websocket handshake without attempting to change the meaning of the HTTP layer before the handshake has completed. Section 4.1 seems to make it clear that the intended scheme on the wire is https for secure WebSocket connections. If HTML5 or a client SDK in any other language decided to formalize sse as the scheme to denote Server-Sent Events URLs, it would have no bearing on the HTTP network traffic to setup an SSE event stream because it is a client-side API contract that is not needed by the protocol layer. IMHO, the wss scheme is an equivalent client-side API contract that is equally not needed by the protocol layer. > Having separate schemes for protocols that must start out life as HTTP >> forces questions about port defaulting for those schemes. Since the "ws" >> and "wss" schemes ended up being treated the same as "http" and "https" = in >> terms of port defaulting, there doesn't seem to be much value in >> propagating the "wss" scheme to the server especially when the :protocol >> header is present with value "websocket". >> > > > you can of course imagine :protocol changing to be websocket2 with the > scheme not changing. > Looking forward to hearing your perspective. Kind Regards, John Fallows CTO, Kaazing > > > >> >> Hope this is helpful. >> >> Kind Regards, >> John Fallows >> CTO, Kaazing >> >> On Fri, Oct 27, 2017 at 5:33 AM Patrick McManus >> wrote: >> >>> thanks for the feedback.. start with a tightly scoped issue first: >>> >>> On Thu, Oct 26, 2017 at 3:47 PM, John Fallows >>> wrote: >>> >>>> >>>> Note also that the scheme is "https" rather than "wss" because the HTT= P >>>> 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. >>>> >>> >>> I don't think so.. there is no https target URL in play here. 7540 >>> 8.1.2.3 talks about non http schemes allowing the use of HTTP to intera= ct >>> with non-http services this way. >>> >>> >>> -- >> *John Fallows* >> CTO* | *=F0=9F=93=9E+1.415.215.6597 <(415)%20215-6597> >> *----------------------------------------------------------------------* >> KAAZING >|< when real-time matters=E2=84=A2 >> kaazing.com/kwic | Blog >> | Twitter >> > -- *John Fallows* CTO* | *=F0=9F=93=9E+1.415.215.6597 *----------------------------------------------------------------------* KAAZING >|< when real-time matters=E2=84=A2 kaazing.com/kwic | Blog | Twitter --94eb2c12370e961242055c984189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Patrick,

=
Thanks for taking the time to address my feedback - comments inl= ine below. :-)

On Fri, Oct= 27, 2017 at 10:14 AM Patrick McManus <pmcmanus@mozilla.com> wrote:
On Fri, Oct 27, 2017 at 12:42 PM, John Fallows <john.fallows@kaazing.com> wrote:
Hi Patrick,

There seems to be = no requirement to change the scheme to wss = for a functional handshake using TUNNEL met= hod plus :protocol header with value websocket.

I'm not changing the scheme. It was also wss in h= ttp/1.1 as well - its just that scheme does not typically appear on the wir= e in that protocol.

This one is subtle.=

Imagine if the client JavaScript API had elected to use:
=C2=A0 new WebSocket("https://example.com/chat",= ["chat", "superchat"])

instead of:
=C2=A0 new WebSocket("= wss://example.com/ch= at", ["chat", "superchat"])
=

then absolutely nothing about the wire protocol would have need= ed to change for HTTP/1.1 WebSocket.

Interestingly, one of the original WebSocket= handshake response headers called WebSocket-Locat= ion, with ws[s] scheme URL, was removed as part of the cleanup to us= e HTTP/1.1 proper.

As mentioned, the invention of the ws= and wss schemes were born from not = using HTTP/1.1 proper from the beginning, including initially having non-HT= TP default ports such as 81=C2=A0for=C2=A0<= font face=3D"monospace">ws=C2=A0instead of = 80.

Server-Sent Events protocol deems it sufficient to offer a GET method with=C2=A0accept = =3D text/event-stream=C2=A0header in the HTTP request, just as WebSo= cket protocol deems it sufficient (in this proposed feedback) to offer a TUNNEL method with := protocol =3D websocket=C2=A0pseudo-header in the HTTP request.

Althoug= h the origins of the WebSocket protocol design initially diverged from HTTP= , after the convergence on HTTP/1.1 proper, there was no remaining justific= ation for the "ws" and "wss" schemes from a network pro= tocol perspective, so they became a client-side concept enforced by the Web= Socket API and used by Proxy Auto-Configuration (PAC).

I'm suggesting we keep= the "wss" scheme as a client-side concept, but also avoid propag= ating it into the HTTP/2 network layer unnecessarily. Including it just for= ces the server to pretend the :scheme =3D https anyway, e.g. the server needs to know about := scheme =3D wss explicitly to treat it as ht= tps while still processing HTTP layer semantics, such as cross-origi= n security.

From an abstraction layering point of view, only WebSocket should dep= end on HTTP, not the reverse.

My reference to 7540 8.1.2.3 explicitly = talks about non http schemes (ftp is the most common). That doesn't mak= e CONNECT/TUNNEL non http.. it just means http is being used to interact wi= th a non-http service..

Good point - I went back and re-read RFC 7540, section 8.1.2.3 reg= arding the :scheme pseudo-header (copied be= low).

:scheme is not restricted to http and htt= ps schemed URIs. A proxy or gateway can translate requests for non-HTTP sch= emes, enabling the use of HTTP to interact with non-HTTP services.
<= /div>

I understood this to mean that an HTTP GET request with scheme ftp<= /font>=C2=A0could be translated by an HTTP/2 proxy or gateway to a certain = usage of FTP wire protocol, such as file retrieval, while an HTTP POST requ= est with scheme=C2=A0ftp=C2=A0might be tran= slated as file upload via FTP wire protocol.

That = desired translation of HTTP <=3D> FTP is captured by the :scheme =3D ftp pseudo-header.

Since we are not trying to translate between HTTP primitives and WebSock= et protocol primitives, the use of :scheme =3D wss= doesn't seem quite right.
=C2=A0
In th= e example, the target URL used by the WebSocket on the wire would be https://server.example.com/chat.

no.. the target url is wss://server.example.com/ch= at and this is a definition of how to use h2 to access that service. Th= is document doesn't say anything about how to access an https:// scheme= d url. If the URL were https://server.example.com it would be rejected by a websocket cli= ent which requires ws or wss. PAC evaluation also expects ws/wss schemes.
=C2=A0
I think you mi= ssed my point - sorry, my fault.

I was trying to d= raw a clear distinction between a particular WebSocket client implementatio= n requirement (W3C territory) and the WebSocket protocol requirement (IETF = territory).

From a network protocol perspective, a= ll HTTP requests aimed at a particular origin server, whether they use GET method or the proposed=C2=A0TUNNEL method, would seem to logically have the same=C2=A0= http or https scheme.

Singling out T= UNNEL=C2=A0method with=C2=A0:protocol =3D w= ebsocket=C2=A0to present a different :schem= e =3D wss just seems to introduce more questions due to the divergen= ce from :scheme =3D https=C2=A0from the net= work protocol perspective.

Unlike a protocol, whic= h represents a single layer in a protocol stack, a scheme often unpacks to = multiple protocol layers forming a protocol stack. For example, the https scheme unpacks to h= ttp over tls over tcp.

In HTTP/2, transmitting=C2=A0:scheme =3D https=C2=A0describes the protocol= stack up to and including HTTP/2 itself. For example, this makes it easier= for the server to construct URLs that can be passed back to the client, wh= ere they can be unpacked into a protocol stack consistent with the original= HTTP/2 request.

If the server is processing the= =C2=A0TUNNEL=C2=A0method with=C2=A0:protocol =3D websocket=C2=A0HTTP/2 request, and=C2= =A0:scheme =3D wss=C2=A0is included, it is = not accurately representing the protocol stack up to and including HTTP/2, = because the WebSocket protocol handshake has not yet completed.
<= br>
Say, at the HTTP/2 layer of the protocol stack, the server wa= nts to issue a 302 redirect to path /chat2 in absolute form. It might most naturally c= onstruct the redirect location using a consistent = :scheme, :authority and in this case= replacement :path. However, with :scheme =3D wss the constructed location would not b= e correctly formed as it would be requesting an HTTP redirect to wss://example.com/chat2= .

Instead the HTTP/2 layer at the serve= r would need to know to pretend=C2=A0= :scheme =3D wss=C2=A0was really=C2=A0:scheme =3D https=C2=A0so it could send the redirect to=C2=A0= https://example.com/chat2=C2=A0as intended. Then the client HTT= P/2 layer would need to somehow infer that the redirected request should se= nd=C2=A0:scheme =3D wss=C2=A0even though th= e redirect URL had scheme=C2=A0https<= /span>.

Alternatively, the HTTP/2 layer at the ser= ver would actually send the redirect to=C2=A0wss://example.com/chat2, and then expect the HTTP/2 layer at the client to understand how to f= ollow that redirect as if=C2=A0https<= /span>=C2=A0and presumably include=C2=A0:scheme =3D wss.

Putting=C2=A0:scheme =3D wss=C2=A0on the wire forces = a tight coupling between the HTTP/2 and WebSocket subsystems for non-obviou= s benefit, while the tight coupling can be avoided by putting=C2=A0:scheme =3D https=C2=A0on the wire=C2= =A0instead.

=C2=A0
The cross-origin security checks (etc) are enforced by HTTP-specifi= c validation of the request headers prior to processing the TUNNEL method semantics. If the validation fails, then the= request never became a WebSocket. Only after a successful HTTP response is= provided can the pair of HTTP/2 streams be considered a WebSocket.


maybe y= ou're confusing protocol with scheme?

No, they are quite distinct as described above.<= /div>

The problem with sending=C2=A0:scheme =3D wss=C2=A0at the HTTP layer is that it = represents a promise of what will happen after the HTTP layer instead of th= e current state up to and including the HTTP layer. That promise of what= 9;s to come is already captured by the=C2=A0:proto= col =3D websocket=C2=A0pseudo-header so :sc= heme =3D wss doesn't appear to be adding much value.
<= br>
Even after this was cleaned up to be a fully HTTP/1.1 complia= nt handshake, as part of the work in IETF HyBi, the "ws" and &quo= t;wss" schemes remained in use on the client (only) but were deliberat= ely not exposed on the wire.

<= /div>
whether or not the scheme is on the wire is a property of http = - not something hybi was ever in a position to standardize. (thus the '= cleanup'.)

one weird note of 7230 5.3.2 requir= es that servers MUST accept absolute form requests even though clients are = forbidden from sending them to non-proxies. The absolute form here would be= wss://.. so this is an h1 thing too it just wasn't obvious.
<= /div>

That interpretation doesn= 't seem consistent with RFC-6455, section 4.1 regarding absolute form (= copied below).

The "Request-URI"= part of the request MUST match the /resource
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 name/ defined in Section 3 (a relative URI) or be an a= bsolute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http/https URI<= /b> that, when parsed, has a /resource name/, /host/,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 and /port/ that match the corresponding ws/wss URI= .

WebSocket servers should accept https:= //... as absolute form (not wss://...), then process the Upgrade: websocket handshake without attempting to change the= meaning of the HTTP layer before the handshake has completed.

Section 4.1 seems to make it clear that the intended schem= e on the wire is https for secure WebSocket= connections.

If HTML5 or a client SDK in any othe= r language decided to formalize sse as the = scheme to denote Server-Sent Events URLs, it would have no bearing on the H= TTP network traffic to setup an SSE event stream because it is a client-sid= e API contract that is not needed by the protocol layer.

IMHO, the wss scheme is an equivalen= t client-side API contract that is equally not needed by the protocol layer= .
=C2=A0
Having separate schemes for protocols that mus= t start out life as HTTP forces questions about port defaulting for those s= chemes. Since the "ws" and "wss" schemes ended up being= treated the same as "http" and "https" in terms of por= t defaulting, there doesn't seem to be much value in propagating the &q= uot;wss" scheme to the server especially when the :protocol header is = present with value "websocket".
=

you can of course imagine :prot= ocol changing to be websocket2 with the scheme not changing.

Looking forward to hearing your p= erspective.

Kind Regards,
John Fallo= ws
CTO, Kaazing
=C2=A0
=

=C2=A0

Hope this is helpful.

Kind Regards,
John Fallows
CTO, Kaazing
=

On Fri, Oct 27, 2017 at 5:33 AM Patrick M= cManus <pmcman= us@mozilla.com> wrote:
thanks for the feedback.. start with a tightly scoped issue fir= st:

On Thu, Oct 26, 2017 at 3:47 PM, John Fallows <= john.fallows@kaazing.com> wrote:
=
Note also that the scheme is "https" rather than &quo= t;wss" because the HTTP request is still "https" until *afte= r* the TUNNEL has been established, and the TUNNEL protocol being selected = is based on :protocol header rather than the :scheme header.

I don't think so.. there is no https = target URL in play here.=C2=A0 7540 8.1.2.3 talks about non http schemes al= lowing the use of HTTP to interact with non-http services this way.

=

--
John Fallows
CTO=C2=A0 | =C2=A0=F0=9F=93=9E+1.4= 15.215.6597
-----------= -----------------------------------------------------------
<= /div>
KAAZING=C2=A0>|<=C2=A0=C2=A0when real-time matters=E2= =84=A2
<= font>kaazing.com/= kwic=C2=A0=C2=A0| =C2=A0Blog=C2=A0=C2=A0| =C2=A0Twitter=C2=A0
<= div dir=3D"ltr">--
John Fallows
CTO=C2=A0 | =C2=A0=F0=9F=93=9E+1.= 415.215.6597
--------------= --------------------------------------------------------
KAAZING=C2=A0>|<=C2=A0=C2=A0when real-time matters=E2=84= =A2
--94eb2c12370e961242055c984189-- From nobody Sat Oct 28 18:17:54 2017 Return-Path: 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 3241913DC3B for ; Sat, 28 Oct 2017 18:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 DwU6OAStfE_v for ; Sat, 28 Oct 2017 18:17:51 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 851F213954B for ; Sat, 28 Oct 2017 18:17:51 -0700 (PDT) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by linode64.ducksong.com (Postfix) with ESMTPSA id 843533A01B for ; Sat, 28 Oct 2017 21:17:49 -0400 (EDT) Received: by mail-lf0-f43.google.com with SMTP id a16so11089273lfk.0 for ; Sat, 28 Oct 2017 18:17:49 -0700 (PDT) X-Gm-Message-State: AMCzsaWmuMt3Soiu+7ASY01GTZLqi+qs5XKqaHVln5iq7eRr2RA4UebP kh7sqc5wQ5+07Mj6391BfwrX92InxTREdVtlzZg= X-Google-Smtp-Source: ABhQp+SlNoR8iMMQYbK7ebnpdMBcpbSaG8t+CNetWzimCp9i2sD+m6UbSEF+vOEvk5cKgOEwRIkHAF5PahGysO6dUaU= X-Received: by 10.46.78.2 with SMTP id c2mr1841904ljb.11.1509239868291; Sat, 28 Oct 2017 18:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Sat, 28 Oct 2017 18:17:47 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Sat, 28 Oct 2017 21:17:47 -0400 X-Gmail-Original-Message-ID: Message-ID: To: John Fallows , Alexey Melnikov Cc: Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="f403045ec2ea3b0282055ca54a7d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 01:17:53 -0000 --f403045ec2ea3b0282055ca54a7d Content-Type: text/plain; charset="UTF-8" +Alexey That interpretation doesn't seem consistent with RFC-6455, section 4.1 > regarding absolute form (copied below). > > *The "Request-URI" part of the request MUST match the /resource* > * name/ defined in Section 3 (a relative URI) or be an absolute* > * http/https URI that, when parsed, has a /resource name/, /host/,* > * and /port/ that match the corresponding ws/wss URI.* > That's really interesting and is the only argument I find at all compelling.Thanks. Basically its saying that the URI of the GET is not the websockets URI used in other places such as the cache and the pac. Which is totally insane imo. Given that H1 doesn't ever let you send an absolute URI to an origin server that's a total nop of a statement. I'm not feeling particularly bound by it if it is just broken and not used. I'm not sure I'm even willing to put my name on continuation of it :) Maybe Alexey, as 6455 author, can weigh in on what the target-uri was meant to be.. but none of this is changing my mind on what it needs to be. You're connecting to a wss:// target; the scheme is therefore wss://. That doesn't mean it can't be carried on h2 or quic (if there were a definition) and it doesn't mean its scheme changes when it is. (as for redirects, yes the redirect needs to be to wss.. otherwise the client should fail the connection as non ws[s] uris are not legal for websocket clients.. as for the same server getting a mixture of schemes that's something h2 is meant to support.. that's why the scheme is explicit.). > > --f403045ec2ea3b0282055ca54a7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+Alexey

=
That interpretation doesn't seem consistent with RFC-6455, section= 4.1 regarding absolute form (copied below).

= The "Request-URI" part of the request MUST match the /resource=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 name/ defined in Section 3 (a= relative URI) or be an absolute
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 http/https URI that, when parsed, has a /resource name/, = /host/,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and /port/ that match = the corresponding ws/wss URI.

That's really interesting and is the only argument= I find at all compelling.Thanks.=C2=A0 Basically its saying that the URI o= f the GET is not the websockets URI used in other places such as the cache = and the pac. Which is totally insane imo.

Given th= at H1 doesn't ever let you send an absolute URI to an origin server tha= t's a total nop of a statement. I'm not feeling particularly bound = by it if it is just broken and not used. I'm not sure I'm even will= ing to put my name on continuation of it :)

Ma= ybe Alexey, as 6455 author, can weigh in on what the target-uri was meant t= o be.. but none of this is changing my mind on what it needs to be. You'= ;re connecting to a wss:// target; the scheme is therefore wss://. That doe= sn't mean it can't be carried on h2 or quic (if there were a defini= tion) and it doesn't mean its scheme changes when it is.
=
(as for redirects, yes the redirect needs to be to wss.. oth= erwise the client should fail the connection as non ws[s] uris are not lega= l for websocket clients.. as for the same server getting a mixture of schem= es that's something h2 is meant to support.. that's why the scheme = is explicit.).

=C2=A0

--f403045ec2ea3b0282055ca54a7d-- From nobody Sun Oct 29 01:37:15 2017 Return-Path: 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 258A813F933 for ; Sun, 29 Oct 2017 01:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl 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 pkcPpuUiOB-0 for ; Sun, 29 Oct 2017 01:37:13 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD3913F8F3 for ; Sun, 29 Oct 2017 01:37:13 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 32FF359807A for ; Sun, 29 Oct 2017 01:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=annevk.nl; bh=iD5JdeQ /XTbUwmAj8rMgt/auE9Q=; b=Hu9sHQGghG4LykPMGPBh7MaTrnMC9MSobWokNHe cm04uY24rDyZ9E6R0MfKmWtXGZYAxq304mljGwza0L+KmQgToipm9TKCjwUVNDKj ild5cNWoSQWCpajhOojSo6BTZOWRheRlLw0w9dxMcpTHkKQafGrjsoWavkIUu/k0 rQ5I= Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 987DE598077 for ; Sun, 29 Oct 2017 01:37:11 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id z3so10596770wme.5 for ; Sun, 29 Oct 2017 01:37:11 -0700 (PDT) X-Gm-Message-State: AMCzsaWn1duwjy8OTRQ45a+0GStW3JeIqPfywnQrHX2UWO/g98CYdLDD i0LLuDQ173HJSTXnowyqhKS+lCpfO0uRTQ4ylQ== X-Google-Smtp-Source: ABhQp+RoAa9FNToHz2tiSkRm3e0vZExJwAglzAk9yNw+EO0bL86ApCLtyMOpGzLCb1V5ADCxqJCNkodDEq0jcmHg6Mw= X-Received: by 10.80.218.72 with SMTP id a8mr5667709edk.221.1509266229963; Sun, 29 Oct 2017 01:37:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.240.141 with HTTP; Sun, 29 Oct 2017 01:37:09 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Anne van Kesteren Date: Sun, 29 Oct 2017 09:37:09 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus Cc: John Fallows , hybi , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 08:37:14 -0000 On Fri, Oct 27, 2017 at 7:13 PM, Patrick McManus wro= te: > I'm not changing the scheme. It was also wss in http/1.1 as well - its ju= st that scheme does not typically appear on the wire in that protocol. My r= eference to 7540 8.1.2.3 explicitly talks about non http schemes (ftp is th= e most common). That doesn't make CONNECT/TUNNEL non http.. it just means h= ttp is being used to interact with a non-http service.. FWIW, we do change the scheme from the API perspective: https://fetch.spec.whatwg.org/#websocket-protocol (details in section 6.2). The reason for that is 1) the handshake is a simple HTTP request 2) it makes it a lot easier to share HSTS, CSP, Mixed Content logic, etc. So by the time it gets to the protocol there's no ws/wss. I think ws/wss was largely a legacy thing from when we still thought it wouldn't require HTTP at all. --=20 https://annevankesteren.nl/ From nobody Sun Oct 29 22:10:19 2017 Return-Path: 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 B52C413F7D9 for ; Sun, 29 Oct 2017 22:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 PIsVGW7Mbbfq for ; Sun, 29 Oct 2017 22:10:15 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 9A63813F546 for ; Sun, 29 Oct 2017 22:10:15 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id r25so10551356pgn.4 for ; Sun, 29 Oct 2017 22:10:15 -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=mh7MWpjhcU9rM74JriRh1gPBNnm2UL4D2Cxq8jk9K3U=; b=MGT3in3J/NsPsg1zNbaCVgWdckNAPqbkvwWxIvJpJ7AyL62Hsi5L/Rim8GGuNJfcN3 AX3zsSP+XnUp0lGbia5zxEZP22EdnA6AN+MXg7+nzHBiDRMHUslXLmBtxoZV4oXL0feC 19LbhCOSDwCOtPM6+N7gq19xneDtRHSwUSMX/cradd8GzoT73p8qiXHDb42/0bODgMyU Qn2OevdJ4zD64HQ4HT/7y6t2be4Nsuygho0gtZqinOBeIl1DWX+5QJOEKcMHBTB3wAUW IabykqAQM6tGf510wAMZleO3VwdUrrTCaxfzdaELr3pAQWTKrZjMnFJjvwOqlupL84A/ aXhg== 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=mh7MWpjhcU9rM74JriRh1gPBNnm2UL4D2Cxq8jk9K3U=; b=qvNcOAr0cdjQmLVapLoCfOqGTC1f4Zg/j1ZlolrQT3x5wOGK9SxqtYvvmiXA0KGYcH XeWcvGFah/BEHtgOpVG0tCvs0NJaeDD418EQMWCjNe7HPxQzo6P7lUCzBPmujCmVyIm4 ssH8kA6RGDzCC1mxIBLp7uc/5AzkFK0LByFkJWIETQSbNdyxvBFqS4tMmxMywGnMddY0 ZXwmLJ3eRrS4E8WNtcgSnEQ4Y4SjIpTsJ4GvU/8iLqaZeHxShmPrd3QSuwG9lTygZeei ed+KX5RsffHOgzrL7XlSpVR7X0MsXG1pOGMktx+KGIyI+8mjegGArwru8oZq5ksGZrrt YqFA== X-Gm-Message-State: AMCzsaULVQsODkOA2doKAC9oRXroUDzqcFHTB6UGhQe5F4dxvitAwqCR aYO6klrBWktKjcfYUIV4LaY/NlIPU7B+rJSR5f8= X-Google-Smtp-Source: ABhQp+SwyIFx5U4w6YOwhWeazYb9qroc1wsRqaQo+bSWNIYwBUMhZ+OUDoFly6dKk1x4occ6MFkcAGakvYrtjrpBhy8= X-Received: by 10.84.248.142 with SMTP id q14mr6291292pll.39.1509340215103; Sun, 29 Oct 2017 22:10:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.131 with HTTP; Sun, 29 Oct 2017 22:10:14 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Kazuho Oku Date: Mon, 30 Oct 2017 14:10:14 +0900 Message-ID: To: Patrick McManus Cc: hybi , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hybi] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 05:10:18 -0000 Hi, Thank you for working on the draft. I am happy to see WebSockets coming to HTTP/2, and I like that the proposal tries to make changes caused by the transition minimal. The biggest issue I wonder if we can continue using HTTP/1 headers for WebSocket parameter negotiation (e.g., Sec-WebSocket-Version, Sec-WebSocket-Protocol), instead of sending them in DATA frames. The reason I ask this is because unless we keep them as headers, it would become impossible to implement a ws-on-h2 to ws-on-h1 proxy without dealing with the details of the WebSocket protocol. In HTTP/1, it has been possible to implement a HTTP proxy that supports WebSockets, without the knowledge of sub-protocol negotiation. This is because all the parameters were negotiated through the use of the HTTP headers, and a proxy could simply forward them as-is. All the thing that a proxy has been required to do is to look at the Upgrade header and the status code, and start running a bi-directional tunnel once the upstream server sends a 101 response. With the -01 proposal, the same feature is retained only when a proxy forwards from ws-on-h2 client to a ws-on-h2 server. In the case of ws-on-h2 client connecting to ws-on-h1 server (or ws-on-h1 client connecting to ws-on-h2 server), the proxy needs to convert WebSocket-specific values sent in DATA frame to a HTTP header (or vice-versa). I wonder if this is a necessary complication. If not, I would prefer to continue sending all the headers necessary for WebSocket negotiation in HTTP/2 as well. 2017-10-27 2:32 GMT+09:00 Patrick McManus : > 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: > Date: Thu, Oct 26, 2017 at 1:30 PM > Subject: New Version Notification for > draft-mcmanus-httpbis-h2-websockets-01.txt > To: Patrick McManus > > > > 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 > > -- Kazuho Oku From nobody Mon Oct 30 13:56:28 2017 Return-Path: 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 5DD1D13F3EE for ; Mon, 30 Oct 2017 13:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 1EjJQ7JpxyTb for ; Mon, 30 Oct 2017 13:56:25 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id CE62813F567 for ; Mon, 30 Oct 2017 13:56:24 -0700 (PDT) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id EBFBB3A1DA for ; Mon, 30 Oct 2017 16:56:23 -0400 (EDT) Received: by mail-lf0-f49.google.com with SMTP id e143so4431652lfg.12 for ; Mon, 30 Oct 2017 13:56:23 -0700 (PDT) X-Gm-Message-State: AMCzsaUbjVGiodDicB3bLjDVbDoPWkqe0kqwRapK6TwBgJO8+k+IjTTv 9eMnvUOTguWM9Wwnm+qisE8749BZNgFHIeOfhRE= X-Google-Smtp-Source: ABhQp+Smr1v+1/8cFRKIvTxDaL40aCS/Y9S6k9TBu0RYUsjGD0OjHKq/1vlOf8H4kcnzxQaklRIguOmQ0jUxeT+ADjk= X-Received: by 10.25.21.233 with SMTP id 102mr3306090lfv.252.1509396982735; Mon, 30 Oct 2017 13:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Mon, 30 Oct 2017 13:56:20 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Mon, 30 Oct 2017 16:56:20 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Kazuho Oku Cc: Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="001a11408126fb2b32055cc9de7c" Archived-At: Subject: Re: [hybi] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:56:27 -0000 --001a11408126fb2b32055cc9de7c Content-Type: text/plain; charset="UTF-8" I think the consensus is to move the websockets parameters (sub-protocol, etc..) in h2 HEADERS. -02 will reflect that. On Mon, Oct 30, 2017 at 1:10 AM, Kazuho Oku wrote: > Hi, > > Thank you for working on the draft. I am happy to see WebSockets > coming to HTTP/2, and I like that the proposal tries to make changes > caused by the transition minimal. > > The biggest issue I wonder if we can continue using HTTP/1 headers for > WebSocket parameter negotiation (e.g., Sec-WebSocket-Version, > Sec-WebSocket-Protocol), instead of sending them in DATA frames. > > The reason I ask this is because unless we keep them as headers, it > would become impossible to implement a ws-on-h2 to ws-on-h1 proxy > without dealing with the details of the WebSocket protocol. > > In HTTP/1, it has been possible to implement a HTTP proxy that > supports WebSockets, without the knowledge of sub-protocol > negotiation. This is because all the parameters were negotiated > through the use of the HTTP headers, and a proxy could simply forward > them as-is. All the thing that a proxy has been required to do is to > look at the Upgrade header and the status code, and start running a > bi-directional tunnel once the upstream server sends a 101 response. > > With the -01 proposal, the same feature is retained only when a proxy > forwards from ws-on-h2 client to a ws-on-h2 server. In the case of > ws-on-h2 client connecting to ws-on-h1 server (or ws-on-h1 client > connecting to ws-on-h2 server), the proxy needs to convert > WebSocket-specific values sent in DATA frame to a HTTP header (or > vice-versa). > > I wonder if this is a necessary complication. If not, I would prefer > to continue sending all the headers necessary for WebSocket > negotiation in HTTP/2 as well. > > 2017-10-27 2:32 GMT+09:00 Patrick McManus : > > 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: > > Date: Thu, Oct 26, 2017 at 1:30 PM > > Subject: New Version Notification for > > draft-mcmanus-httpbis-h2-websockets-01.txt > > To: Patrick McManus > > > > > > > > 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 > > > > > > > > -- > Kazuho Oku > --001a11408126fb2b32055cc9de7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the consensus is to move the websockets parameters= (sub-protocol, etc..) in h2 HEADERS. -02 will reflect that.

On Mon, Oct 30, 2017 a= t 1:10 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
Hi,

Thank you for working on the draft. I am happy to see WebSockets
coming to HTTP/2, and I like that the proposal tries to make changes
caused by the transition minimal.

The biggest issue I wonder if we can continue using HTTP/1 headers for
WebSocket parameter negotiation (e.g., Sec-WebSocket-Version,
Sec-WebSocket-Protocol), instead of sending them in DATA frames.

The reason I ask this is because unless we keep them as headers, it
would become impossible to implement a ws-on-h2 to ws-on-h1 proxy
without dealing with the details of the WebSocket protocol.

In HTTP/1, it has been possible to implement a HTTP proxy that
supports WebSockets, without the knowledge of sub-protocol
negotiation. This is because all the parameters were negotiated
through the use of the HTTP headers, and a proxy could simply forward
them as-is. All the thing that a proxy has been required to do is to
look at the Upgrade header and the status code, and start running a
bi-directional tunnel once the upstream server sends a 101 response.

With the -01 proposal, the same feature is retained only when a proxy
forwards from ws-on-h2 client to a ws-on-h2 server. In the case of
ws-on-h2 client connecting to ws-on-h1 server (or ws-on-h1 client
connecting to ws-on-h2 server), the proxy needs to convert
WebSocket-specific values sent in DATA frame to a HTTP header (or
vice-versa).

I wonder if this is a necessary complication. If not, I would prefer
to continue sending all the headers necessary for WebSocket
negotiation in HTTP/2 as well.

2017-10-27 2:32 GMT+09:00 Patrick McManus <pmcmanus@mozilla.com>:
> 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 <mcmanu= s@ducksong.com>
>
>
>
> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-01.txt<= br> > has been successfully submitted by Patrick McManus and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mcmanus-httpbis-h2= -websockets
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bootstrapping WebSockets with= HTTP/2
> Document date:=C2=A0 2017-10-26
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
> URL:
> https://www.ietf= .org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-01.txt
> Status:
> https://datatracker.ietf.o= rg/doc/draft-mcmanus-httpbis-h2-websockets/
> Htmlized:
> https://tools.ietf.org/html/<= wbr>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=3Ddraft-mcmanus-httpbis-h2-websockets-01
>
> Abstract:
>=C2=A0 =C2=A0 This document defines a mechanism for running the WebSock= et Protocol
>=C2=A0 =C2=A0 [RFC6455] over a single stream of an HTTP/2 connection. >
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>



--
Kazuho Oku

--001a11408126fb2b32055cc9de7c--