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?
Related
I am trying to capture an old application that didn't honour the system's proxy setting. The only config I can change is the server IP address.
Capturing the packets with Wireshark. Without the Charles reverse proxy, I can see requests after the first three handshake requests.
With the reverse proxy, the connection stuck after the handshake requests.
I notice that when Charles received a request and connecting to somewhere but it will just stuck there:
Following is the config of the reverse proxy (Remote host removed):
Any help, solution and workarounds would be appreciated!
First of all, your app uses neither HTTP nor HTTPS. Studying screen shot of successful connection gives some details on protocol used:
the first message after handhsake is originated by server contrary to common client-server approach, where client is responsible for sending query. This fact is enough to cross out HTTP and HTTPS.
payload data isn't human-readable, so it's a binary protocol.
based on PUSH flags, protocol is much more likely to be message-based rather than stream-based
So client establishes connection, immediately gets some command from server and replies it. Then communication continues. I can't guess exact protocol. Port number might be irrelevant, but even if it's not, there are only few protocols using 4321 port by default. Anyway, it can always be custom private protocol.
I'm not familiar with Charles, but forwarding arbitrary TCP stream is probably covered by its port forwarding feature rather than reverse proxy. However, I don't really see any benefits in sending traffic through Charles in this case, capturing data on your PC should be enough to study details.
If you are looking for traffic manipulation, for arbitrary TCP stream it's not an easy task, but it must be possible. I'm not aware of suitable tools, quick googling shows lots of utils, but some of them looks applicable to text based stream only, so deeper study is required.
Reason for Failure
It may be because you are requesting a local IP address from a remote scope, which Charles proxy doesn't applies. For POS(Proof Of Statement), please refer to the below link
https://www.charlesproxy.com/documentation/faqs/localhost-traffic-doesnt-appear-in-charles/
Solution
So In order to solve the problem for the current scenario, use
http://192.168.86.22.charlesproxy.com/
Note: The url that you request will only be proxied properly by Charles not any other proxy services.
I want to take a look at the direct encrypted https traffic of my requests. I got a server and 2 clients. With client 1 there are no problems. client 2 gets problems if the request exceeds a certain text-size. I was able to decrypt the traffic and found that client 1 extends my SOAP request every 3996 signs by an extra "f9c"-pattern. Client 2 is not doing this which is probably causing the problem on the serverside. But that is not all. If I use fiddler to decrypt the https request the server also throws an exception. So my guess is that the client is probably adding something on the https encryption too. That is why I want to take a look at this but I cannot figure out how to force fiddler to show this to me. I only get the http traffic if I disable https-decryption that shows my the handshake between client and server. So what can I do here?
problem solved.
the "f9c"-pattern is just the hex value for 3996-bytes. The problem was that client 1 was correctly chunking the http-request. Client 2 on the contrary was sending a single block and just setting the content-length of the http-request. Therefore I do not need to take a look anymore on the encrypted request.
I'm starting with Websockets and I have a problem.
I have a sails.js application that uses sockets to update the client side.
On the client side it makes an API call using socket.get("/api/v1/actor...") to bring all the items of the database. When I see what the WebSocket's traffic on the Chrome console:
As you can see, the connection has been established and the API call has been correctly done through the socket.
The problem is, there is no answer from the server, not even an error.
If I make the same API call using ajax, I get response, but it doesn't work using WebSockets.
Any idea what might be producing this behavior?
EDIT: I add here the code here that processes the request and this one here that sends the request, but the problem is that it never execute this code. I think we we are closer to the find the cause, since we think it has to do with a network problem. We figured there is an F5 reverse-proxy which is not properly set up to handle websockets
The answer didn't make any sense now that I've seen the code that's why I've edited it. I only answered because I could't comment on your question and ask you for the code.
Your calling code seems correct and the server side of things the process of response should be handled automatically by the framework, you only need to return some JSON in the controller method.
I instantiated a copy of the server (just changed the adapters to run it locally) and the server replied to the web socket requests (although I only tested the route '/index').
Normally when the problems are caused by a reverse proxy the socket simply refuses to connect and you can't even send data to server. Does the property "socket.socket.connected" returns true?
The best way to test is to write a small node application with socket.io client and test it in the same machine that the application server is running, then you can exclude network problems.
I have set up lighttpd with mod_websocket as discussed in Dom Bramley's blog entry (except that I am using a BeagleBone Black with Debian Wheezy instead of an rPi.)
https://www.ibm.com/developerworks/community/blogs/B-Fool/entry/setting_up_an_mqtt_websocket_gateway_for_raspberry_pi?lang=en
[During the lighttpd/mod_websocket build process I was asked if I wanted to patch the server and I said yes.]
I have the mosquito MQTT broker running on the same host and publishing on various topics.
When I try to connect to the broker with a browser client via the web socket, I can see that everything works okay in terms of the http upgrade to websocket and forwarding the connection request to mosquitto. Mosquitto gets the connection request and accepts it. However, the response that gets back to the browser does not include the Sec-Websocket-Protocol header echoing the subproto specifier mqttv3.1 that was in the original upgrade request. The client correctly rejects this answer and the connection is shut down.
The javascript error from mqttws31.js:912 is "Sent non-empty Sec-Websocket-Protocol header but no response is received." With Wireshark, I can see that this is true; the 101 Switching Protocols response has headers Upgrade, Connection, and Sec-Websocket-Accept, but nothing else.
My mod_websocket config file defines host, port, type, and subproto the same as Dom's example, and I can see from various debug statements that the request gets all the way to Mosquitto correctly.
Can anyone suggest how to get the Websocket-Protocol header to be included in the response? It must work, Dom wrote a blog post describing how he did it!
I think recent versions of mod_websocket broke/removed subprotocol support, but can't confirm it right now. You could try an earlier version, or use a dedicated websocket to tcp gateway like WSS
https://github.com/stylpen/WSS/
The mod_websocket author (Norio Kobota) quickly and effectively resolved this issue for me by making an update to mod_websocket. The fix is currently in a development branch, and available on github. Our discussion is part of the thread for mod_websocket issue 28.
Briefly, the use case that I have (pre-written client library and existing TCP backend) is much less flexible than a roll-your-own client and server combination with respect to connect-time protocol negotiation. However, in my case I don't really need any flexibility or negotiation with the backend, and so mod_websocket can just echo the configuration it has been given without having to dive into the details of the subprotocol.
The updated mod_websocket echoes the subproto entry from its config file during websocket handshake which satisfies the MQTT client library.
So now I have two solutions for adapters between websocket clients and TCP backends! Thanks all for your help.
Doug Johnson
I understand from various sources that the HTTPS handshake is the heaviest part of using HTTPS. I'm using POSTs internally between my servers to communicate information and would like to use HTTPS for it. I wondered how long the actual HTTPS handshake lasts/"stays open"? Is it re-done for each POST I'm sending to a server, or what is the lifetime?
The SSL handshake is only done at the beginning of a session and is mainly about generating a shared session key that is used to encrypt all later traffic.
You can find a very good description of the handshake here.
I believe the handshake occurs on connection (ie, as part of the SSL negotiation). It you use HTTP keep-alive connections then the handshake only occurs once as long as the connection is active.
I don't know the particulars, but I'm sure the handshake is supposed to occur only when the session is started. It would be too expensive otherwise.
Edit: Here's a nice description of the process.