Web sockets allows you to support cross domain access however you want
by checking the "Origin:" header. If you only want to allow your own
domain, then you can compare the Origin equals your own domain and if
you want to allow some domains or all domains you can whitelist as you
want.

According to the lastest version of the draft spec's security concern:
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-55#section-7

One thing to understand is that WebSockets are not really HTTP.
WebSockets handshakes may start out looking like an HTTP in the
initial request and initial response but that only so that it's
possible for a web server serving HTTP today could be used to handle
the requests and be able to tell that it's a WebSocket and internally
switch over to handling the request as a WebSocket internally.

Websockets are not like HTTP though in that they are full duplex
communication (real two way communication). It avoids some of the
tricks you have to do with AJAX Comet/Long polling/http streaming by
giving the browsers something more like traditional TCP/IP sockets to
communicate back the server while still working through HTTP proxies
and firewalls.

Jetty, the web server that Twitter uses today on the streaming side
supports WebSockets in its latest version
(http://blogs.webtide.com/gregw/entry/jetty_websocket_server). Most of
the web socket server implementations that exist today are built on
top of traditional web servers, but they don't use epoll or any kind
of event based async sockets (most design around having a single
thread handle the connections for a user) and so they are unable to
handle massive numbers of simultaneous open concurrent connections
like you can with Jetty or FriendFeed's Tornado
(http://www.tornadoweb.org/).

I would love to see a streaming server implementation using WebSockets
from Twitter, not only just for access from web browsers but from
desktop clients that support websockets. There are some doors that
open with that like being able to send back messages to Twitter up the
socket (like sending a tweet, or changing the paramaters of what we
are filtering on the stream, or request all sorts of things that you
would have to do on the querystring and have to reconnect to change
them).

Zac Bowling
@zbowling

On Sun, May 16, 2010 at 11:29 AM, John Kalucki <j...@twitter.com> wrote:
> I did a quick reading, and I couldn't tell if WS connections are
> restricted back to the domain of the calling page, or if arbitrary
> connections are allowed. If the former, there may not be a reason for
> the Streaming API to support this. If the latter, perhaps there's a
> valid use case.
>
> Looking at the protocol itself, this wouldn't be trivial to support,
> but it might not be that bad either. We'll have to keep an eye on the
> installed browser base and see when this might make sense.
>
> It is too bad that they didn't allow HTTP connections with incremental
> byte reads in addition to WB connections on that interface. I'm sure
> they had their reasons.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
>
>
> On Sat, May 15, 2010 at 3:22 PM, Abraham Williams <4bra...@gmail.com> wrote:
>> I'm not particularly familiar with the specifics of WebSockets but here is
>> the draft documentation: http://dev.w3.org/html5/websockets/
>> I don't see Chrome Extensions as being any different from desktop
>> applications as they are both manually installed by the user on their
>> desktop.
>> Abraham
>>
>> On Sat, May 15, 2010 at 09:02, John Kalucki <j...@twitter.com> wrote:
>>>
>>> The first release of User Streams is not intended for web clients due
>>> to capacity constraints.
>>>
>>> http://apiwiki.twitter.com/ChirpUserStreams
>>> "
>>> All services, mobile and browser-based clients must not use Streaming
>>> until we've sorted out Desktop clients at some scale. One problem at a
>>> time.
>>> "
>>>
>>> That being said, of course we'd like to encourage experimentation with
>>> other client types, so that clients can evolve as we scale out the
>>> service.
>>>
>>> While others at Twitter are well-versed in the latest browser
>>> technologies, I'm totally and willfully ignorant. If you could give a
>>> brief summary of how the existing Streaming API does not work for
>>> WebSockets, that might be helpful. What's missing?
>>>
>>> -John Kalucki
>>> http://twitter.com/jkalucki
>>> Infrastructure, Twitter Inc.
>>>
>>>
>>>
>>> On Fri, May 14, 2010 at 9:38 PM, Cezar Sá Espinola <ceza...@gmail.com>
>>> wrote:
>>> > Hey guys,
>>> > Quick question, are there any plans on supporting WebSockets protocol
>>> > for
>>> > the Streaming API?
>>> > That'd be awesome for browser based Twitter clients (i.e. Google Chrome
>>> > extensions). Without this it'll be very difficult for this kind of
>>> > client to
>>> > lavarage benefit from the upcoming user streams.
>>> > Thanks a lot for all your hard work,
>>> > Cezar Sá Espinola
>>> > @cezarsa
>>
>>
>>
>> --
>> Abraham Williams | Developer for hire | http://abrah.am
>> @abraham | http://projects.abrah.am | http://blog.abrah.am
>> This email is: [ ] shareable [x] ask first [ ] private.
>>
>

Reply via email to