I have Faye ruby server as rack app. I starts it with Puma. In Puma's output I see the next
127.0.0.1 - - [10/Apr/2015 15:32:37] "POST /faye HTTP/1.1" HIJACKED -1 0.0059
What does it mean and how can I avoid this? If I use Thin I have nothing like this.
This means that the Rack Socket Hijacking Protocol is used. Not sure why it isn't used with Thin, or maybe, Thin just doesn't log it.
As Jorg says, this means it's using socket hijacking. That's not a bad thing, and not a problem. You should expect it when using Faye or any other Comet or long-polling method of pushing content to the browser.
Related
I want to use websocket in sinatra in my social game and first i wanted to use em-websockets but then i found a good gem for websockets and it use em-websockets .. it's called sinatra-websocket here ..
https://github.com/simulacre/sinatra-websocket
and i have a problem that i found also in the example of the gem here
https://github.com/simulacre/sinatra-websocket/blob/master/examples/echochat.rb
the problem is if any of the clients are idle for while (not sending or receiving) .. all the connections got an error on the browser (the connection is interrupted while loading) ..and then no client can send anything to the server by websocket !!!
anyone knows what's happening ?? thanks a lot !!
I have a ruby on rails app serving an API. It's legacy and we've already built a replacement on a more suitable stack, so no such suggestions in that direction needed :)
But we need to improve the performance on it regarding latency of response. I noticed keepalive was off. So I enabled it in apache. Now the static files from that server are responding with connection: keep-alive in the response headers. But the api (dynamic, rudy generated xml) still responds with connection: close. Sure enough it appears to be closing the connection on the client. Passenger is the Apache module used.
How can I make it use keepalive for the ruby generated responses?
Thanks
I can not reproduce this. I just tried, with Apache 2.2.3, passenger 3.0.12
The responses from my rails app do not have connection:close, they are kept alive. (They in fact have a Connection: Keep-Alive too, although I don't think HTTP 1.1 requires that.
So long as my apache has KeepAlive On.
This might sound really naive but I would really find a descriptive answer helpful.
So, my question is this:
I can use Firebug to look at AJAX requests made from any website I visit. So, am I right in saying that I wouldn't be able to examine the same communication between the client and the server if the website choses to use Websockets? In other words, does this make it more secure?
No. Not at all. Just because the browser does not (yet) have a tool to show WebSocket traffic, doesn't make it any more secure. You can always run a packet sniffer to monitor the traffic, for example.
No, because there will be other ways beside the browser-build in tools to read your traffic.
Have a try: Install and run Wireshark and you will be able to see all packets you send and receive via Websockets.
Depends on the application. If you are fully Ajax without reloading the document for data then I would think websockets would provide a better authentication for data requests then a cookie session in regards to connection hijack. Given that you are using SSL of course.
Never rely on secrecy of algorithm cause it only gives you false sense of security. Wiki: Security by obscurity
Remember that browser is a program on my computer and I am the one who have a full control over what is send to you, not my browser.
I guess it's only matter of time (up to few months IMO) when developer tools such as Firebug will provide some fancy tool for browsing data send/received by WebSockets.
WebSockets has both an unencrypted (ws://) and encrypted mode (wss://). This is analogous to HTTP and HTTPS. WebSockets protocol payload is simply UTF-8 encoded. From a network sniffing perspective there is no advantage to using WebSockets (use wss and HTTPS for everything at all sensitive). From the browser perspective there is no benefit to using WebSockets for security. Anything running in the browser can be examined (and modified) by a sufficiently knowledgeable user. The tools for examining HTTP/AJAX requests just happen to be better right now.
I'm trying to write a server for a webSocket connection. I've read the spec (76, not 75) carefully. I'm using minefield as the browser.
When I try to create a WebSocket from javascript in the browser:
var ws = new WebSocket("ws://localhost:8766/hoho");
The browser responds with
"Firefox can't establish a connection to the server at ws://localhost:8766/hoho."
My server is getting a valid client handshake request, it sends back the response and then boom.
I've run every example handshake example I can find through my server and I match the given responses exactly in every instance. I'm pretty confident that the return byte stream is correct. I don't need help debugging my code, it's doing what I mean it to do. I need help debugging my use of the handshake protocol since when I give minefield what I think is a correct response it laughs at me.
My question is this: How can I debug this thing? I can think of two possibilities.
Is there any way to get minefield to tell me WHY it's rejecting my handshake?
Is there a working, public, webSocket server service on the web? If there is, I can proxy it, watch the byte streams in both direction and figure out where mine is different.
Does anyone have any ideas in these directions or any other ideas?
Thanks for any help.
I'm in the process of debugging a similar situation, and the tool I'm relying on most is netcat, with some additional use of openssl. Shut down your websocket server and run nc -l 8766. That lets you record exactly what headers are being sent. Turn the websocket server back on and use nc 8766 to paste in those same headers and see the result. openssl s_client -connect localhost:443 will let you make the request with ssl, if that is in your mix.
From there, make sure the responses conform completely to the websocket handshake protocol. For instance, my problem right now is that my responses have Connection: close, which is no good.
About the 2nd possibility.
Yes, there is a websocket server out there.
the jWebSocket demo server at http://jwebsocket.org/demos/chat/chat.htm
hope this helps
Added: Echo socket server at: http://www.websocket.org/echo.html
Here's a jsfiddle that I made from http://www.websocket.org echo websocket server which works in Chrome but not in Firefox 6: http://jsfiddle.net/awDLc/
It is adjusted to use MozWebSocket rather than WebSocket, but perhaps that isn't enough?
Does anyone know if there is a way to prevent Sinatra from sending the 'Connection: close' header in its responses?
To be clear, I have a very simple
get '/path' do
puts "Some (~200 byte long) string"
end
But, after looking at the output in a network analyser, I see it's sending the Connection: close header right after the HTTP/1.1 200 OK, which I'd like to stop!
Ah ha! It seems Mongrel, the server my Sinatra app was running on, doesn't support Keep-Alive. so I just did:
set :server, 'thin'
after gem install thin and everything seems to be working better!
I don't speak Ruby at all, and the Sinatra site isn't terribly clear on what it is (is it a framework for Ruby?) so I might be completely off my rocker here, but:
Connection: close is sent by your Web server when keep alives are turned off. For scalability reasons, keep alives are generally considered to be step one on things to turn off in your server. To be fair, there's a school of thought both ways, particularly when Ajax is involved.
I use nginx for my Django work (I'm thinking it's similar), and I have keep-alives turned off in nginx like this:
14:58 jsmith#lateralus% grep alive /etc/nginx/nginx.conf ~
keepalive_timeout 0;
Apache uses KeepAlive (see here).
If Sinatra is its own Web server, I can't find any documentation to turn keep alives on, and I'll go ahead and eat the fact that I look like an idiot.