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

Hi Andy, Kari, 

Thanks for the comments and discussion here!

As Kari mentioned, this does specify two new :protocol names and is a fairly straightforward extension to RFC8441.

In terms of negotiation of subprotocols/next protocol there are a few options that come to mind: 

(1) Treat this like TCP and leave it up to the data running over this arbitrary bytestream to negotiate what it wants to do. Note that hostname/port/etc. are all just as available here as to TLS. That’s some of what’s currently in the document, but I suspect we’ll want more than that, for many of the reasons outlined in your emails. 
However, folks using existing protocols transported over H/2, which is one of the main use cases here, are probably okay with just (1). This also enables exactly the same API surface/mechanisms that are currently used for that protocol over TLS, except now it’s transparently using a single transport connection underneath. 

(2) The path is present and can be useful in designating different “endpoints” for different types of services. This is also in the document, and aims to look very similar to how WebSocket handles this in 8441. As Andy notes, this doesn’t quite provide a scenario where the client offers something and the server picks it. If you have multiple protocols and just need different “endpoints”, you can likely use this in combination with (1) above without too much trouble. 

(3) Incorporate a header that contains a list of next protocols and lets the responder choose. This can be very useful, but it’s not strongly defined in the current version of the document. I’d be open to adding it, and offhand it seems like it would look pretty much like WebSocket’s version in 8441.

(4) A different mechanism that would be helpful here? Ideally, it would be common to anyone and any protocol wanting to use the extended CONNECT handshake.

Operatively, the main point of the extended CONNECT part is to say “here’s this great thing for WebSocket, let’s generalize it to the base of what other :protocol values will need”.. 
In doing that, we also define a new :protocol that covers a number of use cases, but most certainly not everything that the extended CONNECT method could be useful for. 
Future :protocol values should be able to build on top of this, since it defines a minimal set (i.e. without WebSocket specific items) of functionality that is needed for generic use of that handshake. 

Thanks,
Eric



> On Mar 22, 2019, at 10:24 PM, Andy Green <andy@warmcat.com> wrote:
> 
> 
> 
> On March 23, 2019 1:32:53 AM GMT+08:00, Kari Hurtta <hurtta-ietf@elmme-mailer.org <mailto: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