Re: draft-kinnear-httpbis-http2-transport questions

On March 23, 2019 1:32:53 AM GMT+08:00, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
>Andy Green <andy@warmcat.com>: (Fri Mar 22 08:28:49 2019)
>> 
>> What it creates is a single registered upgrade type "bytestream" that
>is 
>> anonymous and has no description of what protocol or versioning or 
>> subframing is inside it.
>> 
>>  From ws perspective, it's the same as a ws protocol that doesn't 
>> provide subprotocol names... the vhost can only offer one of those
>and 
>> if you made that mistake, this doesn't have the escape hatch of 
>> subprotocol negotation that ws has.  If different vendors feel that 
>> different things should go in the anonymous transport, more than one 
>> vendor's products couldn't talk to the same vhost.
>
>It is not per vhost, it is per URL which includes also path.

From a ws perspective the subprotocols buy you something different than path.

Ws also lets the upgrade use the path, since the path is there... and that's useful since the path may bind to url space on the vhost for purposes like basic auth requirement, which can also then apply to the http part of the ws upgrade cleanly.  In ws what's on the path is left wholly for a server + specific ws protocol to define or ignore.

Subprotocol is a negotiation...the client lists what he can handle and the server picks the best one he can handle, once at upgrade time, and informs the client in the response.  So you can deal with multiple versions in the field, rolling upgrades, and even eg, population of devices with different vendor protocols and quirks once.

Subprotocol is standardized outside of some arbitrary vendor url schema.  So packet inspection can know what is supposed to be in the upgraded stream.

Subprotocols allow the server to have one implementation which may be used by different vhosts, these may then be administratively enabled and disabled per-vhost at the server.

Clients can use the negotiation to support different server capabilities in one implementation cleanly.

There are other pressures on path to match applications and url space layout in the vhost, so it's not a free choice just for upgrades.

>Same vhost can provide different protocol on different path.
>
>https://tools.ietf.org/html/rfc8441#section-4
>
>|   o  On requests that contain the :protocol pseudo-header field, the
>|      :scheme and :path pseudo-header fields of the target URI (see
>|      Section 5) MUST also be included.
>
>https://tools.ietf.org/html/draft-kinnear-httpbis-http2-transport-01#section-3.1
>
>|   Endpoints using this mechanism to establish byte stream or datagram
>|   tunnels over HTTP/2 streams follow the CONNECT handshake procedure
>|   defined in [RFC6455].  However, instead of supplying "websocket"
>for
>|   the :protocol psuedo-header field to indicate a WebSocket
>connection,
>|   they specify "bytestream" or "datagram" to indicate a byte stream
>or
>|   datagram connection, respectively.
>|
>|   The :scheme and :path psuedo-headers are required by [RFC6455]. 
>The
>|   scheme of the target URI MUST be set to "https" for both byte
>stream
>|   and datagram tunnels.  The path is used in the same manner as for
>the
>|   WebSocket protocol, and MAY be set to "/" (an empty path component)
>|   if not desired for use.
>
>You are saying that path is not enough to identify desired endpoint ?

No, you could put, eg, ?subprotocol=xxx on the path... it's not the same as ws style subprotocol negotiation but it will select a protocol.  You can put &quirks= &version= too.

However...

 - that draft does not define conventions for doing that

 - the draft specifies only two opaque, abstract transport :protocol names

Actually as it is if a vhost gets this request, he can't be sure of the client assumptions about what he'll read into the url and then no idea what's going to be coming from the opaque protocol name.  Anything that thought it might inspect the packet must learn everybody's random path conventions...

They can get around it by making the :protocol specify what it is in there, but that must go in the registry each time... it'd work for 'ethernet-encapsulation' or so though.

Or they can normatively tell how to specify the subprotocol another way.

>Is subprotocols really used on Websocket ?

Yes.

>I suspect that path is changed instead.

There are lots of ways to do it.  From what I have seen from many people using ws the first time, they are happy to ignore subprotocol and path and get on with their implementation.  But then they want to support more than one protocol on the same vhost.  Ws upgrades have no normative binding to server url space, they exist outside it unless the server implementation enforces something about path... they are normatively bound by subprotocol name.

-Andy

>/ Kari Hurtta

Received on Friday, 22 March 2019 21:24:46 UTC