Re: WebSocket2

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sun, 02 October 2016 07:17 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C4F12B050 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 2 Oct 2016 00:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.917
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b09R3Mx8y45T for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 2 Oct 2016 00:17:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58AB112B00E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 2 Oct 2016 00:17:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bqaxy-0008Rk-Cu for ietf-http-wg-dist@listhub.w3.org; Sun, 02 Oct 2016 07:13:42 +0000
Resent-Date: Sun, 02 Oct 2016 07:13:42 +0000
Resent-Message-Id: <E1bqaxy-0008Rk-Cu@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1bqaxx-0008R6-1e for ietf-http-wg@listhub.w3.org; Sun, 02 Oct 2016 07:13:41 +0000
Received: from smtpvgate.fmi.fi ([193.166.223.36]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1bqaxt-0000cS-IT for ietf-http-wg@w3.org; Sun, 02 Oct 2016 07:13:39 +0000
Received: from virkku.fmi.fi (virkku.fmi.fi [193.166.211.54]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (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 shell.siilo.fmi.fi by virkku.fmi.fi with ESMTP id u927D7eN027109 ; Sun, 2 Oct 2016 10:13:08 +0300
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id u927D7xT001935 ; Sun, 2 Oct 2016 10:13:07 +0300
Received: by shell.siilo.fmi.fi id u927D7q1001934; Sun, 2 Oct 2016 10:13:07 +0300
Message-Id: <201610020713.u927D7q1001934@shell.siilo.fmi.fi>
In-Reply-To: <CAG-EYCiqq7KsYq6it9qsc-HLh3PZWtexX3LE=rSio6SLHeVPew@mail.gmail.com>
References: <CAG-EYCjx5=tExsjOJ+_-5p95Vp=Wfaz8JihDAAykDQpL64T4TA@mail.gmail.com> <20161001051700.245FA10F65@welho-filter1.welho.com> <CAG-EYCiXDYjmZ4r_8q31-UKQBG5=U53xOh1vef3-TJCVuytmdw@mail.gmail.com> <201610011936.u91JaZlG008986@shell.siilo.fmi.fi> <CAG-EYCiqq7KsYq6it9qsc-HLh3PZWtexX3LE=rSio6SLHeVPew@mail.gmail.com>
To: Van Catha <vans554@gmail.com>
Date: Sun, 2 Oct 2016 10:13:07 +0300 (EEST)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
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: smtpVgate.fmi.fi: 3 received headers rewritten with id 20161002/01132/01
X-Filter: smtpVgate.fmi.fi: ID 1132/01, 1 parts scanned for known viruses
X-Filter: virkku.fmi.fi: ID 0684/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Sun, 02 Oct 2016 10:13:08 +0300 (EEST)
Received-SPF: none client-ip=193.166.223.36; envelope-from=hurtta@siilo.fmi.fi; helo=smtpVgate.fmi.fi
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: lisa.w3.org 1bqaxt-0000cS-IT 445d423801147d84674e0cfb6221eee0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/201610020713.u927D7q1001934@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32445
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Van Catha <vans554@gmail.com>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.


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0006.html

>             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)
https://tools.ietf.org/html/rfc7540

8.1.  HTTP Request/Response Exchange
https://tools.ietf.org/html/rfc7540#section-8.1

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


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0006.html


|                    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

https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt

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

  :schema: http
or
  :schema: https

then it is cachable.


Hypertext Transfer Protocol (HTTP/1.1): Caching
https://tools.ietf.org/html/rfc7234


2.  Overview of Cache Operation
https://tools.ietf.org/html/rfc7234#section-2

|   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


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0008.html

> :scheme is perfect! Wow.  If we could pass ws/wss for example as the scheme
> that
> fits perfectly. Looking at https://tools.ietf.org/html/rfc3986#section-3.1
> the spec for schemes
> it seems ws and wss are perfectly valid schemes to use and are registered;
> http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.


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
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
August 12, 2014

but it used also

SETTINGS frame with SETTINGS_WEBSOCKET_CAPABLE


That draft is expired. 
)

Hypertext Transfer Protocol Version 2 (HTTP/2)
https://tools.ietf.org/html/rfc7540


8.1.2.3.  Request Pseudo-Header Fields
https://tools.ietf.org/html/rfc7540#section-8.1.2.3

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

Hopefully

8.  HTTP Message Exchanges
https://tools.ietf.org/html/rfc7540#section-8

then does not apply.



/ Kari Hurtta