Re: WebSocket2

Kari Hurtta <> Sun, 02 October 2016 07:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50C4F12B050 for <>; Sun, 2 Oct 2016 00:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.917
X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b09R3Mx8y45T for <>; Sun, 2 Oct 2016 00:17:46 -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 58AB112B00E for <>; Sun, 2 Oct 2016 00:17:46 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bqaxy-0008Rk-Cu for; Sun, 02 Oct 2016 07:13:42 +0000
Resent-Date: Sun, 02 Oct 2016 07:13:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bqaxx-0008R6-1e for; Sun, 02 Oct 2016 07:13:41 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bqaxt-0000cS-IT for; Sun, 02 Oct 2016 07:13:39 +0000
Received: from ( []) (envelope-from by (8.13.8/8.13.8/smtpgate-20160114/smtpVgate) with ESMTP id u927D8xW015480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Oct 2016 10:13:08 +0300
Received: from by with ESMTP id u927D7eN027109 ; Sun, 2 Oct 2016 10:13:08 +0300
Received: from ([]) by with ESMTP id u927D7xT001935 ; Sun, 2 Oct 2016 10:13:07 +0300
Received: by id u927D7q1001934; Sun, 2 Oct 2016 10:13:07 +0300
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
To: Van Catha <>
Date: Sun, 2 Oct 2016 10:13:07 +0300 (EEST)
From: Kari Hurtta <>
CC: Kari hurtta <>, HTTP working group mailing list <>
X-Mailer: ELM [version ME+ 2.5 PLalpha41]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: 3 received headers rewritten with id 20161002/01132/01
X-Filter: ID 1132/01, 1 parts scanned for known viruses
X-Filter: ID 0684/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 ( []); Sun, 02 Oct 2016 10:13:08 +0300 (EEST)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: AWL=0.049, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.099, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bqaxt-0000cS-IT 445d423801147d84674e0cfb6221eee0
Subject: Re: WebSocket2
Archived-At: <>
X-Mailing-List: <> archive/latest/32445
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Van Catha <>om>: (Sun Oct  2 00:21:19 2016)
> I just do not see the necessity.  We have custom headers in HTTP/1.1 for a
> long time and no one has had a problem with it.

My reason was:

| There [you] start using of HTTP/2 DATA
| frames. These usage however differ
| very much from usage of http -request
| and response.

Your use is not that send all request body
on DATA frames and then send response body
on DATA frames to different direction.

>             HTTP/2 was designed from the
>  very beginning to not support 2 way streaming like websocket provides
>  currently for HTTP/1.1.  

Yes, that is reason why I suspect that you need negotate this.

Hypertext Transfer Protocol Version 2 (HTTP/2)

8.1.  HTTP Request/Response Exchange

|   A client sends an HTTP request on a new stream, using a previously
|   unused stream identifier (Section 5.1.1).  A server sends an HTTP
|   response on the same stream as the request.
|   An HTTP message (request or response) consists of:
|   1.  for a response only, zero or more HEADERS frames (each followed
|       by zero or more CONTINUATION frames) containing the message
|       headers of informational (1xx) HTTP responses (see [RFC7230],
|       Section 3.2 and [RFC7231], Section 6.2),
|   2.  one HEADERS frame (followed by zero or more CONTINUATION frames)
|       containing the message headers (see [RFC7230], Section 3.2),
|   3.  zero or more DATA frames containing the payload body (see
|       [RFC7230], Section 3.3), and
|   4.  optionally, one HEADERS frame, followed by zero or more
|       CONTINUATION frames containing the trailer-part, if present (see
|       [RFC7230], Section 4.1.2).
|   The last frame in the sequence bears an END_STREAM flag, noting that
|   a HEADERS frame bearing the END_STREAM flag can be followed by
|   CONTINUATION frames that carry any remaining portions of the header
|   block.

and so on

|   An HTTP request/response exchange fully consumes a single stream.  A
|   request starts with the HEADERS frame that puts the stream into an
|   "open" state.  The request ends with a frame bearing END_STREAM,
|   which causes the stream to become "half-closed (local)" for the
|   client and "half-closed (remote)" for the server.  A response starts
|   with a HEADERS frame and ends with a frame bearing END_STREAM, which
|   places the stream in the "closed" state.

First question: Is there http/2 proxies at all?

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

I found at least on there

  :method: GET

I also note that required :schema was missing, If it was

  :schema: http
  :schema: https

then it is cachable.

Hypertext Transfer Protocol (HTTP/1.1): Caching

2.  Overview of Cache Operation

|   Each cache entry consists of a cache key and one or more HTTP
|   responses corresponding to prior requests that used the same key.
|   The most common form of cache entry is a successful result of a
|   retrieval request: i.e., a 200 (OK) response to a GET request, which
|   contains a representation of the resource identified by the request
|   target (Section 4.3.1 of [RFC7231]).  However, it is also possible to
|   cache permanent redirects, negative results (e.g., 404 (Not Found)),
|   incomplete results (e.g., 206 (Partial Content)), and responses to
|   methods other than GET if the method's definition allows such caching
|   and defines something suitable for use as a cache key

> :scheme is perfect! Wow.  If we could pass ws/wss for example as the scheme
> that
> fits perfectly. Looking at
> the spec for schemes
> it seems ws and wss are perfectly valid schemes to use and are registered;

Using :schema other than http or https, may be negotation what you need
with proxy.

> Where is the problem in HTTP/2 that would disallow schemes different from
> http and https, I do not see
> anything related to this?

My viewpoint is just opposite. ( I suppose that you do not want
negotiate with proxy. )

You need negotiate your usage with next hop. Hopefully using your scheme
is recognised as negotation by proxies.

( That idea of using :scheme ws or wss was also on

WebSocket over HTTP/2
August 12, 2014

but it used also


That draft is expired. 

Hypertext Transfer Protocol Version 2 (HTTP/2)  Request Pseudo-Header Fields

|   o  The ":scheme" pseudo-header field includes the scheme portion of
|      the target URI ([RFC3986], Section 3.1).
|      ":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.

Other schemas are allowed.


8.  HTTP Message Exchanges

then does not apply.

/ Kari Hurtta