Re: WebSocket2

Van Catha <> Sat, 01 October 2016 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 669B112B09C for <>; Sat, 1 Oct 2016 11:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.116
X-Spam-Status: No, score=-8.116 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 GW4Lfba7QUWO for <>; Sat, 1 Oct 2016 11:25:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5390D12B078 for <>; Sat, 1 Oct 2016 11:25:25 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bqOuO-0002rd-4k for; Sat, 01 Oct 2016 18:21:12 +0000
Resent-Date: Sat, 01 Oct 2016 18:21:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bqOuJ-0002px-Lm for; Sat, 01 Oct 2016 18:21:07 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bqOuH-0004Ht-8Y for; Sat, 01 Oct 2016 18:21:07 +0000
Received: by with SMTP id t7so134098020qkh.2 for <>; Sat, 01 Oct 2016 11:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uqsSq94TLwRaGS6v4bs1A2aEtWJ2yTVLQcFUHLpkWCs=; b=wF3KvY2ax9eoCKl5+Bm3D4aPCeQ29obAR95uyDj068Bqabxbh27bdsvEbS57+Qk2TJ ZBaFO1yL5QxmVL9MeeeaM3hzFtW6e+M9acoAzdZxMnysd6TO28WecHkvZzhagW0jCj7V vScs3pjniSQg09NjAXSgD0hMhoKNkyr7gNfp2QP+EZNrJ3c3a1wxHfc1uChO0qQJcZmO N5pFypkxFEBkK4iFLICAwn7R/w1W632VUPmCIgk/89sr4E4qKLkCkvFANuatpgJ1zdl7 BeIjmuBCL1qF+tm9xjCPtmBWLP4o7oHQoFz3nXalndvssFlP3gOFTgqto9mWXIb5ipoQ t3wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uqsSq94TLwRaGS6v4bs1A2aEtWJ2yTVLQcFUHLpkWCs=; b=OjFkQaJ5gH706zurwmJKnwH8rjBj4rEz5H1AU3UEEUKwqDYbb2uBl7iU8taTzB96Ov aLzlitnUfXuuUuiCPFE+zOjxt84qOTk7n3glEyK6eDKZX3e5uvmFU4LqOGWmP1lypmN9 wZfY3pvx5NOmqJsdw7sgb4izngjc3ECQrKAxUC0Y2K85IauAH3AQqGXwFf705DRQz2cm OGko7yHvS9AX4At4lGURYn+VlPmTyrp/awrcxagdaSWvzHdrCiflDk/uUlhgBo2nuxMr GIo5ymY9aHAX9raU1AlV3D58D+vd23HQdW2sTnuOuot8uU0zidpx2NuoYXpCquV6xiUh nRaQ==
X-Gm-Message-State: AA6/9RkOEcbA0evbFji+rO7O6yqSk80QwTK0fj0pcgtTcmLJE4/NtT1jrmbWhjGodOCIrQPUIHIGp7GnRCq74w==
X-Received: by with SMTP id y1mr12691063qke.150.1475346038920; Sat, 01 Oct 2016 11:20:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 1 Oct 2016 11:20:38 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Van Catha <>
Date: Sat, 1 Oct 2016 14:20:38 -0400
Message-ID: <>
To: Kari hurtta <>
Cc: HTTP working group mailing list <>
Content-Type: multipart/alternative; boundary=94eb2c06fb04921d1d053dd1c4a9
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-1.238, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bqOuH-0004Ht-8Y dfdeb8c4c11d5d92b51b62abf41b9acb
Subject: Re: WebSocket2
Archived-At: <>
X-Mailing-List: <> archive/latest/32437
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Correct. Because HTTP2/ DATA frames essentially provide flow control only
and WebSocket2 frames need to be delivered in full to the underlying client
API. A single WebSocket2 frame could be broken up into multiple HTTP/2 Data
frames depending how large the MAX negotiated size is by the endpoints.

The proxy problem circles around back to the implementation. Perhaps a
header in the request could be included saying to not cache anything, if
the proxy caches things well its the proxies fault.  Also if the proxy is
not aware of WebSocket2 this should not matter, the proxies job is to
forward everything as it came.  As long as the proxy would forward the
websocket2-[version|compression] headers to the server and forward what the
server replies with there should be no problems.  Again if the proxy is
"smart" and decides to cache the response (which did not specify any
headers related to caching) its the proxies fault.  To be more direct the
response may be forced to include headers specifically instructing nothing
should be cached.  Does this work?

I am thinking using SETTINGS frames would be too complex, as that would
require baking WebSocket2 directly into HTTP/2, the way it is now,
WebSocket2 should run over HTTP/2 with minimal resistance since we do not
introduce new settings or HTTP/2 frame types.  HTTP/2 was designed from the
very beginning to not support 2 way streaming like websocket provides
currently for HTTP/1.1.  I think the resistance would be great if adding
WebSocket2 requires adding to the actual HTTP/2 specification.

A side option is to make WebSocket2 its own connection, for example ws2 as
the ALPN type when connecting to a server and to create the connection the
server would send a Alt-Svc with the host+port+other params.  This method
was proposed already, I recall reading it in an RFC.  I think the problem
with this method is now you will have more than 1 connection per server as
well as tons of duplication during the peer handshake. The benefit to this
method is it would be totally separate from HTTP/2, and you would be able
to have a server that strictly only speaks WebSocket2.  I think the
complexity of adoption to do it this way is much higher.

If origin server does not know about WebSocket2 and the request succeeds
that is indeed a problem.  Perhaps the server can reply with the error
header always like websocket2-error: okay; in the case when the WebSocket2
negotation was a success. This way an origin server without WebSocket2 will
reply with 200, and the client will see there is no websocket2-error: okay;
header and promptly notify the client that WebSocket2 negotiation failed.

One problem I find is I have not come across anything in HTTP/2 to make the
handshake smooth except for Alt-Svc header, but what Alt-Svc was designed
for does not fit the use case for WebSocket2.  For example Alt-Svc can only
be sent by a server, a client cannot request an Alt-Svc.

On Sat, Oct 1, 2016 at 1:16 AM, Kari hurtta <>

> > I drafted up a rough RFC to support WebSocket2
> >
> websocket2-over-http2.txt
> ( Very quick reading )
> I'm not sure that is this problem or not
> websocket2-over-http2.txt
> > 4.  Data Framing
> >
> >    Once a handshake has been successfully completed the remote endpoints
> >    can begin to send data to each other.  Data is sent using the HTTP/2
> >    transport layer fully adhering to DATA Frames, Section 6.1 [RFC7540].
> >    WebSocket2 has its own encapsulated framing protocol that is not to
> >    be confused with HTTP/2 DATA Frames.
> So these websockect frames are inside of HTTP/2 DATA frame
> payload.
> > 3.1.  Client Handshake Request
> and
> > 3.2. Server Handshake Reply
> These use HTTP/2 HEADERS frame.
> 1) So consider situation
> +---------------+                     +-----------+
>  +--------+
> |  Web          |  ---- HTTP/2 ---->  |  proxy    | ---- HTTP/2 ----> |
> origin |
> |  browser      |                     |           |                   |
> server |
> +---------------+                     +-----------+
>  +--------+
> "Web server" and "origin server" supports
> "WebSocket2 over HTTP/2" and handshake
> with headers frames succeed.
> "proxy" does not know about
> "WebSocket2 over HTTP/2".
> There there start using of HTTP/2 DATA
> frames. These usage however differ
> very much from usage of http -request
> and response.
> Perhaps "proxy" tries cache response.
> Perhaps there should be some method
> to verify that also "proxy" supports
> "WebSocket2 over HTTP/2".
> One method is to use HTTP/2 SETTINGS -frame.
> (Another method is to use new frame
>  type on HTTP/2. )
> 2) One note
> > 3.2. Server Handshake Reply
> If "origin server"  doe snot know about
> "WebSocket2 over HTTP/2", this looks like
> regular request for page "/ws2".
> This can still succeed.
> >   The server MUST send ONLY ONE of the advertised compression methods
> >   or exclude the websocket2-compression header from the reply,
> >   signaling that no compression will be used.
> Wgen websocket2-compression is excluded, client
> gets /ws2 -resource with
> :status: 200
> and client does not know is this supporting
> "WebSocket2 over HTTP/2" or not.
> Or have I missed something?
> / Kari Hurtta