[hybi] Connection Strategy

[John Fallows <john.fallows at kaazing.com>]

Folks,

As promised, this "Connection Strategy" thread is the first of our
focused IETF discussions outlined previously.

o Connection strategy (now)
o Proxy traversal strategy (next)
o Wire protocol (after that)

The overall goal for this thread is to define a connection strategy
that can be used by future browsers for full-duplex, bidirectional
communication, while integrating with the browser security model.
This connection strategy discussion does not cover any details of the
specific bytes on the wire after the connection has been established,
and is therefore post-connection protocol agnostic.  Hopefully, the
connection strategy would be sufficiently general-purpose to apply
beyond the browser usecase as well.

I plan to present a discussion of the requirements for the connection
strategy, my understanding of the available alternatives and a logical
conclusion based on the preceding analysis.

The browser security model defines the trust boundary between
different code served by different "origin" servers.  The origin
concept is defined by HTML5 [1] as follows:

"The origin of a resource and the effective script origin of a
resource are both either opaque identifiers or tuples consisting of a
scheme component, a host component, a port component, and optionally
extra data."

The Cross-Origin Resource Sharing specification [2] relaxes the
same-origin request constraint by defining an opt-in cross-origin
communication strategy that uses the "Origin" HTTP header.

The rationale for relaxing the same-origin request constraint for HTTP
resources applies equally well to bidirectional communication, which
seems well-matched by an HTTP-based "Origin" header connection
strategy.

There are a number of different bidirectional communication connection
strategies available, such as:
  o crossdomain.xml + separate raw TCP connection
  o HTTP Upgrade in-band to raw TCP
  o Multiple HTTP requests representing independent upstream and downstream
  o Multiple HTTP requests representing overlapping upstream and
downstream (BOSH)

Are there other connection strategies worth considering here?

Note: Using a non-HTTP protocol such as XMPP or BEEP to establish
communication is not a separate connection strategy as it would fall
under crossdomain.xml with separate TCP connection.

In-band upgrade from HTTP to raw TCP (remember discussion of specific
protocol bytes sent over TCP comes later) has some
potentially-significant security benefits over separate control and
data channels such as crossdomain.xml.  The concept of domain is
equivalent to origin but without the port, which can introduce an
attack vector for virtual hosting environments where different users
may have control over different ports.  In this case, the trust model
assumed by the plug-in runtime does not match the trust model enforced
at the server.  In-band upgrade from HTTP using "Origin" header forces
these trust models to match scheme, host and port.

When an in-band HTTP Upgrade is successful, the server responds with a
101 Switching Protocols status code, as specified by RFC2616, section
10.1.2.

"The server understands and is willing to comply with the client's
request, via the Upgrade message header field (section 14.42), for a
change in the application protocol being used on this connection. The
server will switch protocols to those defined by the response's
Upgrade header field immediately after the empty line which terminates
the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so.
For example, switching to a newer version of HTTP is advantageous over
older versions, and switching to a real-time, synchronous protocol
might be advantageous when delivering resources that use such
features."

Using multiple different HTTP requests to provide full-duplex
bidirectional communication is a necessary compromise for today's
browser implementations, and is still subject to the HTTP 2 connection
limit recommended by RFC2616, section 8.1.4 Practical Considerations
[3].  A single post-connection TCP stream makes more efficient use of
the network, and gives us the most flexibility in designing the wire
protocol framing for future browser implementations, and seems to be
more general purpose for use by non-browser clients.

In conclusion, an HTTP Upgrade with Origin header strategy seems to do
a good job of balancing the requirements.

Looking forward to a fun and productive discussion.

Kind Regards,
John Fallows

[1] http://dev.w3.org/html5/spec/Overview.html#origin
[2] http://www.w3.org/TR/access-control/
[3] http://www.ietf.org/rfc/rfc2616.txt

--
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA