Hi Zed et al,
I have downloaded and built Mongrel2 (along with 0MQ and any other
requirements) on Ubuntu 10.10. I've read through the manual and love the
concept.
I am testing a customised version of the chat demo.
Mongrel2 serves the static assets and can pass requests fine to my (ruby)
handlers.
I am having problems, not with the mongrel config etc., but with socket
connections to the route I have allocated in the Mongrel2 config.
If I use the following in routes (note the '@' symbol):
'@updates(.*)': updatehandler
and using jsSocket.js
socket = new jsSocket({ path: '@updates'})
the socket will connect and send and receive data. Unfortunately if I use
any other method than jsSockets to try and connect (e.g. Socket.io, native
EventSource) they complain about the '@' symbol in the route. jsSockets are
fine but they use Flash and i want a non-flash solution as well.
If I change my routes in the mongrel2 config db (note no @ symbol):
'/updates(.*)': updatehandler
Then I issue a
socket = new jsSocket({ path:
'/updates'});socket.send({'data':'test'});
Mongrel2 throws the following error
[ERROR] (src/connection.c:638: errno: Resource temporarily unavailable)
Error parsing request.
and doesn't pass anything through to the handler. Doesn't matter what the
payload of socket.send() is. Seems that the jsSocket implementation (or the
flash it uses) needs the '@' character (although i can't see where it needs
it)
If I connect to this route (/updates) with a native EventSource, I can get
it to work, but EventSource is pretty unsupported.
If I connect to the /updates route with 'socket.io' client (which tries
WebSockets, Flash WebSockets (like jsSocket.js), xhr-multipart etc.) The
WebSockets and flash websockets cause an error like above
(src/connection.c:638) and move on to other methods (which i still haven't
gotten to work but assume will).
If i set WebSocket.swf to debug mode I get the following in the firebug log
window, which shows the request being rejected
[WebSocket] policy file: xmlsocket://localhost:843
[WebSocket] connected
[WebSocket] request header: GET /updates/flashsocket HTTP/1.1 Upgrade:
WebSocket Connection: Upgrade Host: localhost:6767 Origin:
http://localhost:6767 Cookie: _session_id=107214bc91652e099fd6ce23f84215cf
Sec-WebSocket-Key1: xxsnipxx Sec-WebSocket-Key2: xxxsnipxxxx
[WebSocket] sent key3: xsnipx
[WebSocket] response header: HTTP/1.1 400 Bad Request Content-Type:
text/plain Connection: close Content-Length: 11 Server:
Mongrel2/1.5-adad5ca877
Any ideas what I'm doing wrong? It could be something very simple as I'm
trying to take on-board quite a few new concepts at the same time.
Can I turn on debugging in Mongrel2's request checking code to see why the
request is failing?
Is the tech in this space (the client browser using sockets) too young?
Should I just fall back to long-poll?
Thanks in advance for any help, it will be appreciated.
Regards,
Paul McConnon
On Wed, Apr 06, 2011 at 02:26:21PM +0100, Paul McConnon wrote: > Hi Zed et al, > > If I use the following in routes (note the '@' symbol): > > '@updates(.*)': updatehandler > > > the socket will connect and send and receive data. Unfortunately if I use > any other method than jsSockets to try and connect (e.g. Socket.io, native > EventSource) they complain about the '@' symbol in the route. jsSockets are > fine but they use Flash and i want a non-flash solution as well. > > > If I change my routes in the mongrel2 config db (note no @ symbol): > > '/updates(.*)': updatehandler > > Then I issue a > > socket = new jsSocket({ path: > '/updates'});socket.send({'data':'test'}); > > Mongrel2 throws the following error > > [ERROR] (src/connection.c:638: errno: Resource temporarily unavailable) > Error parsing request. > > and doesn't pass anything through to the handler. Doesn't matter what the > payload of socket.send() is. Seems that the jsSocket implementation (or the > flash it uses) needs the '@' character (although i can't see where it needs > it) The WebSockets support we have is very experimental, and restricted heavily to avoid the various security flaws in the protocol. You can connect to Mongrel2 with websockets, and your handler will get the first request, then after that it is one direction only from the handler to the browser, not bi-directional. This blocks all those attacks the WebSockets folks were complaining about (well, most of them) but that means you have to use it for async notification only, then have your web app do json http requests like normal. Kind of annoying, but that's where it stands. Now, for the routing, the problem is probably that Socket.io is doing WebSockets and WebSockets uses the regular HTTP request stuff to send, so / would work. Where they are most likely making a mistake is in applying this restriction to jssockets, which can send anything. I'd have to grab it and play with it to be sure, but most like it's a bug in their code for having the restriction in the first place. Any chance you can put a simple sample of socket.io up and I can grab it and play with it? -- Zed A. Shaw http://zedshaw.com/