Re: WebSocket2

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sun, 02 October 2016 13:45 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 2D17612B0B3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 2 Oct 2016 06:45:00 -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 mxtaWxj6Wbha for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 2 Oct 2016 06:44:58 -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 64C4112B060 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 2 Oct 2016 06:44:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bqh0X-0007LU-9N for ietf-http-wg-dist@listhub.w3.org; Sun, 02 Oct 2016 13:40:45 +0000
Resent-Date: Sun, 02 Oct 2016 13:40:45 +0000
Resent-Message-Id: <E1bqh0X-0007LU-9N@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) 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 1bqh0V-0007Kq-UV for ietf-http-wg@listhub.w3.org; Sun, 02 Oct 2016 13:40:43 +0000
Received: from smtpvgate.fmi.fi ([193.166.223.36]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1bqh0T-0004n4-Bd for ietf-http-wg@w3.org; Sun, 02 Oct 2016 13:40:42 +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 u92DeCLG023704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Oct 2016 16:40:12 +0300
Received: from shell.siilo.fmi.fi by virkku.fmi.fi with ESMTP id u92DeCxZ002039 ; Sun, 2 Oct 2016 16:40:12 +0300
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id u92DeCJM029908 ; Sun, 2 Oct 2016 16:40:12 +0300
Received: by shell.siilo.fmi.fi id u92DeBBL029907; Sun, 2 Oct 2016 16:40:11 +0300
Message-Id: <201610021340.u92DeBBL029907@shell.siilo.fmi.fi>
In-Reply-To: <20161002124346.GB9450@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAG-EYChPJpAzoEuNwY3cNz503d0FRbNnDx_9AsNsZyfb5nmN0g@mail.gmail.com> <20161002080030.5F328160CC@welho-filter4.welho.com> <20161002101548.GA9450@LK-Perkele-V2.elisa-laajakaista.fi> <201610021110.u92BAWpi019029@shell.siilo.fmi.fi> <20161002124346.GB9450@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Sun, 2 Oct 2016 16:40:11 +0300 (EEST)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Van Catha <vans554@gmail.com>, 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: 8bit
Content-Type: text/plain; charset="UTF-8"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20161002/02959/01
X-Filter: smtpVgate.fmi.fi: ID 2959/01, 1 parts scanned for known viruses
X-Filter: virkku.fmi.fi: ID 1366/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 16:40:12 +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=-6.6
X-W3C-Hub-Spam-Report: AWL=-0.090, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.641, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bqh0T-0004n4-Bd d26ceb381d1900d43e3d649dcb2a3e81
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/201610021340.u92DeBBL029907@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32450
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>

Ilari Liusvaara <ilariliusvaara@welho.com>om>: (Sun Oct  2 15:43:46 2016)
> On Sun, Oct 02, 2016 at 02:10:32PM +0300, Kari Hurtta wrote:
> > Ilari Liusvaara <ilariliusvaara@welho.com>om>: (Sun Oct  2 13:15:48 2016)
> > > On Sun, Oct 02, 2016 at 11:00:29AM +0300, Kari hurtta wrote:
> > > > 
> > > > (A,B) Is there http  error code which tells that
> > > > that it was unsuppoted :scheme (and not other 
> > > > error, for example wrong :path) ?
> > > > 
> > > > That is needed that client (A) orPbroxy (B) can
> > > > switch Websocket (RFC 6455) negotated over
> > > > HTTP/1.1
> > > 
> > > I don't think there is (and that's a part of the problem) with current
> > > scheme handling.
> > > 
> > > There are probably quite a bit of servers that just plain ignore the
> > > scheme in request.
> > 
> > Hmm. Was reason why
> > 
> > https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
> > 
> > used SETTINGS frame with SETTINGS_WEBSOCKET_CAPABLE parameter ?
> > Seems not mention that reason. 
> > 
> > That means that server needs send SETTINGS_WEBSOCKET_CAPABLE = 1
> > to client indicating that server handles :scheme = ws
> > ( and on that draft SETTINGS_WEBSOCKET_CAPABLE = 1
> >   was sent from client to server. )
>  
> Well, I think the following would work and avoid SETTINGS:
> 
> -> :method ws2
> -> :scheme wss
> -> :authority foo.example
> -> :path /bar
> -> <optional extra parameters, e.g. compression support>
> <- :status 200
> <- sec-ws2-ack 1
> <- <optional negotiated extras>

If we can also assume that proxy does not ignore
   :method = ws2
   :scheme = ws
then this may work.
   
( if :scheme is wss, then proxy gets
  
  :method = CONNECT
  :authority = foo.example:443

  and there is no :scheme or :path
)

But on general forward proxies (also http/1 proxies)
look about scheme  (ie  "http" or "ftp" usually).
So :scheme = ws as unknown scheme may correctly generate
error.

They can otherwise classify :method to four classes:
•   CONNECT,
•   HEAD,
•   GET and other cachable methods, and
•   all other known and unknown methods
I think. So proxies can probably treat 
:method = ws2 as unknown, not cachable method.

I do not know about reverse proxies (load balancers (°)
or cdn).  But these are selected by :authority,
so they usually are not concern.


(  :method = CONNECT already gives that DATA frames
   are not releated to http messaging, so that
   :method = ws2, :scheme = ws or :scheme = wss
   can also be same effect.

https://tools.ietf.org/html/rfc7540#section-8.3

|   After the initial HEADERS frame sent by each peer, all subsequent
|   DATA frames correspond to data sent on the TCP connection.  The
|   payload of any DATA frames sent by the client is transmitted by the
|   proxy to the TCP server; data received from the TCP server is
|   assembled into DATA frames by the proxy.  Frame types other than DATA
|   or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY)
|   MUST NOT be sent on a connected stream and MUST be treated as a
|   stream error (Section 5.4.2) if received.

)

 
> That is, include one header where server acknowledges that it is
> Websockets2 capable. No need for crypto in negotiation because the
> target is already known to be HTTP/2 capable, instead of just known to
> be TCP capable as in case with Websockets(1).
> 
> 
> And unsuccessful request would elict a HTTP response code:
> - 405 for endpoint not supporting Websockets2
> - 404 for endpoit does not exist
> - 403 for "I don't want to talk to you"
> - 401 for "identify yourself".
> <And possibly others>
> 
> 
> As for 301/302/307/308 responses, redirect across schemes would be
> error (channel open failed). And one would need to be very careful about
> redirects out of server's authority (probably channel open failed).
> 
> 
> -Ilari

/ Kari Hurtta

(°) Load balancer can terminate to it

   ∙ IP -protocol  (that make them some kind routers), 
   ∙ TCP -protocol (that make them TCP proxies), or
   ∙ HTTP -protocol (that make them HTTP proxies)

   Only HTTP -proxies are concern on here.