John, I don't mean to be disruptive to your good attempt to bring some order to the wide ranging discussions here.... but... I've relabelled this phase "Message Strategy", because I don't think we can assume that connections are the starting point of this discussion. The references that you cite discuss origins and cross domain as they apply to individual resources - not connections. HTTP allows resources from different origins to be transported over the same connection (proxies). With HTTP, every client to server message semantically has it's own URL, and thus it's own origin/domain. With WebSocket, there is only a single origin/domain that is associated with an entire connection. I don't we should assume either model and should have a discussion about which of these (or other models) we prefer. Indeed some may advocate streaming rather than messaging. It is a later transport discussion when we can discuss how messages might relate to connections etc. ------------- For my contribution to messaging strategy: I advocate messaging over streaming because streamed data is essentially small messages at the quantum of bytes or bits. The arguments for streaming and against messaging are essentially transport discussions about the efficiency of appropriate framing. So let's defer that discussion (and if we have lots of 1 bytes messages, then the framing can be designed to match that). I advocate messaging over connection based abstraction because making connections a non-transport issue can be very limiting. For example, assuming a single origin per connection limits multiplexing and it would not be possible to offload bidirectional SSL to dedicated hardware that terminated all the SSL connections and forwarded messages to the server over fewer connections. Another example is a mashup page that contains javascript from multiple origins, but all of them wish to establish bidirectional communications with the same cross domain. If we assume connection semantics, then multiple connections will be required to the same server just to convey the multiple origins involved. I'm not opposed to specific transports being developed that do allow origin and domain to be assumed for all messages on a connection (and thus not have to send them), but that is a transport efficiency issue and not something that should be part of the central design of the communications paradygm. I agree with John that the definition of Origin should be adopted from his [1] reference. This implies that each message has an associated URL. I think the cross domain access control referred to in [2] should also be closely followed where appropriate - although some of it is very request/response oriented. This needs to be extended to unrequested messages that are sent. So for example, if every message from sent from a server has an associated set of allowed origins, then the user-agent can ensure that the message is not delivered to code from a non allowed origin. While it could be a non-trivial expense to have the list allowable list of origins with every message - I see this as a transport concern to potentially find efficient way (perhaps by association with a connection) to optimize this. So semantically, it is the message that has the allowed origins - but it may be that those are transported by association with a connection or they may be transported with per message meta data. cheers John Fallows wrote: > 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 > _______________________________________________ > hybi mailing list > hybi at ietf.org > https://www.ietf.org/mailman/listinfo/hybi
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.