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

Andy Green <>: (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.

Same vhost can provide different protocol on different path.

|   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.

|   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 ?

Is subprotocols really used on Websocket ?

I suspect that path is changed instead.

/ Kari Hurtta

Received on Friday, 22 March 2019 17:33:29 UTC