Re: WebSocket2

Amos Jeffries <squid3@treenet.co.nz> Sun, 02 October 2016 05:44 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 4C39F12B16D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 1 Oct 2016 22:44:51 -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 pluMM104UVlX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 1 Oct 2016 22:44:48 -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 56EA312B16B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 1 Oct 2016 22:44:48 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bqZW2-0002bg-GP for ietf-http-wg-dist@listhub.w3.org; Sun, 02 Oct 2016 05:40:46 +0000
Resent-Date: Sun, 02 Oct 2016 05:40:46 +0000
Resent-Message-Id: <E1bqZW2-0002bg-GP@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 <squid3@treenet.co.nz>) id 1bqZVw-0002au-6B for ietf-http-wg@listhub.w3.org; Sun, 02 Oct 2016 05:40:40 +0000
Received: from [121.99.228.82] (helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1bqZVu-0005hu-D7 for ietf-http-wg@w3.org; Sun, 02 Oct 2016 05:40:39 +0000
Received: from [192.168.20.251] (unknown [121.98.45.78]) by treenet.co.nz (Postfix) with ESMTP id E7928E6DEB for <ietf-http-wg@w3.org>; Sun, 2 Oct 2016 18:40:04 +1300 (NZDT)
To: ietf-http-wg@w3.org
References: <CAG-EYCjx5=tExsjOJ+_-5p95Vp=Wfaz8JihDAAykDQpL64T4TA@mail.gmail.com> <20161001051700.245FA10F65@welho-filter1.welho.com> <CAG-EYCiXDYjmZ4r_8q31-UKQBG5=U53xOh1vef3-TJCVuytmdw@mail.gmail.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <1dddf4d0-b36f-1128-4f1b-95b1a3da7e38@treenet.co.nz>
Date: Sun, 2 Oct 2016 18:39:40 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAG-EYCiXDYjmZ4r_8q31-UKQBG5=U53xOh1vef3-TJCVuytmdw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.271, BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bqZVu-0005hu-D7 209accc31179a4e2e75d5c91e1913c22
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/1dddf4d0-b36f-1128-4f1b-95b1a3da7e38@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32443
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>

On 2/10/2016 7:20 a.m., Van Catha wrote:
> 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?

If the WebSocket message transmits over HTTP and does not prohibit
caching it can expect to be cached as per the default cacheability of
the method used. Caching is a fundamental part of HTTP that has to be
accounted for and looking at DATA frames alone is not sufficient for that.

We had CONNECT method baked into the WS v1 handshake for exactly this
reason.

Amos