- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sun, 2 Oct 2016 16:40:11 +0300 (EEST)
- To: Ilari Liusvaara <ilariliusvaara@welho.com>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Van Catha <vans554@gmail.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Ilari Liusvaara <ilariliusvaara@welho.com>: (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>: (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.
Received on Sunday, 2 October 2016 13:40:44 UTC