SETTINGS ENABLE_WEBSOCKET ?? | Re: proxy & ENABLE_UPGRADE SETTINGS | Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Amos Jeffries <squid3@treenet.co.nz>: (Sat Nov 11 16:17:01 2017)
> If ":upgrade" has the same optional nature as Upgrade did there is zero 
> point in creating it. Just use the existing Upgrade header in the 
> HEADERS frame. That does not require any negotiation.
> 
> 
> The whole point of SETTINGS is to promise the recipient of that frame 
> that the things mentioned in it will work. No maybes or guessing.
> 
> This guarantee provided by SETTINGS is one of the ways HTTP/2 improves 
> over HTTP/1.1. No more sending maybe-ignored headers and hoping for 
> success a few RTT later. The client can know up front whether that 
> connection is a usable channel for the negotiable feature or not.
> 

Sidenote:

If you want SETTINGS to tell that websocket can be used
over HTTP/2 then 
	:upgrade =
and SETTINGS ENABLE_UPGRADE is no go. No general tunneling
as Kazuho Oku <kazuhooku@gmail.com> as suggesting in that thread:

https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0209.html

> If we adjust the three issues (for example, by allowing any method to
> be specified, and use the existence of :upgrade: pseudo header as a
> signal; use 101 to signal protocol change; use attributes of :upgrade:
> header to specify additional headers required for the upgrade), I
> think the approach would become generic.
> 
> For example, creating a websocket tunnel through HTTP/2 would look like below.

In that case SETTINGS ENABLE_UPGRADE tells nothing what upgrades are available
(or you need to do registry for different 32-bit values of
 ENABLE_UPGRADE to map possible upgrade protocols).

Same to say about SETTINGS  ENABLE_CONNECT_PROTOCOL and
    :protocol = 



You are asking SETTINGS ENABLE_WEBSOCKET then
and that is not proposed on draft-mcmanus-httpbis-h2-websockets-01
either.


/ Kari Hurtta

Received on Saturday, 11 November 2017 19:31:10 UTC