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

John Fallows <> Fri, 27 October 2017 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E30513EF5E for <>; Fri, 27 Oct 2017 09:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i1gl22RfbfQG for <>; Fri, 27 Oct 2017 09:43:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62AA01389C1 for <>; Fri, 27 Oct 2017 09:43:04 -0700 (PDT)
Received: by 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;; 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;; 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 with SMTP id v11mr1048587uae.26.1509122583293; Fri, 27 Oct 2017 09:43:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
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-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

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

In the example, the target URL used by the WebSocket on the wire would be 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 <>

> 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
> talks about non http schemes allowing the use of HTTP to interact
> with non-http services this way.
> --
*John Fallows*
CTO*  |  *đź“ž+1.415.215.6597
KAAZING >|<  when real-time matters™ <>  |  Blog
<>  |  Twitter <>