Re: WebSocket2

[Kari Hurtta <[e-mail]>]

Ilari Liusvaara <[e-mail]>: (Sun Oct  2 15:43:46 2016)
> On Sun, Oct 02, 2016 at 02:10:32PM +0300, Kari Hurtta wrote:
> > Ilari Liusvaara <[e-mail]>: (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.