Inspecting WebSocket Traffic with Chrome Developer Tools

What makes working with WebSockets challenging at times is that the messages are extremely tiny and incredibly fast – making it hard to see them. ;-)

With the updated Chrome Dev Tools,  you can now see the WebSocket traffic coming and going to and from your browser without using tools like Wireshark. Here are the simple steps to make the invisible visible:

1. Be sure that your Chrome version is 20+. At the time of writing this post (May 8, 2012), you need to get Chrome Canary or a fresh Chromium build.
2. Navigate to the Echo demo, hosted on the websocket.org site.
3. Turn on the Chrome Developer Tools.
4. Click Network, and to filter the traffic shown by the Dev Tools, click WebSockets (all the way on the bottom).
5. In the Echo demo, click Connect.

6. Click http://www.websocket.org on the left, representing the WebSocket connection.
7. Make sure you’re on the Headers tab. This tab shows the WebSocket handshake.

Request URL:ws://echo.websocket.org/?encoding=text
Request Method:GET
Status Code: 101 Web Socket Protocol Handshake

Request Headers

Connection:Upgrade
Cookie:__utma=9925811.1340073179.1336513627.1336513627.1336513627.1; __utmb=9925811.4.10.1336513627; __utmc=9925811; __utmz=9925811.1336513627.1.1.utmcsr=websocket.org|utmccn=(referral)|utmcmd=referral|utmcct=/
Host:echo.websocket.org
Origin:http://www.websocket.org
Sec-WebSocket-Extensions:x-webkit-deflate-frame
Sec-WebSocket-Key:DIbT9axdUEPm89HWFqMAZA==
Sec-WebSocket-Version:13
Upgrade:websocket
(Key3):00:00:00:00:00:00:00:00
Query String Parameters view URL encoded
encoding:text

Response Headers

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:content-type
Access-Control-Allow-Origin:http://www.websocket.org
Connection:Upgrade
Date:Tue, 08 May 2012 22:14:46 GMT
Sec-WebSocket-Accept:rKTyKcnJ105fv4ebnspiYbCB9ns=
Server:Kaazing Gateway
Upgrade:WebSocket
(Challenge Response):00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

8. Click the Send button in the Echo demo.

9. 
THIS STEP IS IMPORTANT: To see the WebSocket frames in the Chrome Developer Tools, under Name/Path, click the echo.websocket.org entry, representing your WebSocket connection. This refreshes the main panel on the right and makes the WebSocket Frames tab show up with the actual WebSocket message content.
Note: Every time you send or receive new messages, you have to refresh the main panel by clicking on the echo.websocket.org entry on the left.

The little arrow indicates the direction of the message, after the timestamp, op code, and mask you see the length and contents of the WebSocket message.

This entry was posted in html5, WebSocket. Bookmark the permalink.

21 Responses to Inspecting WebSocket Traffic with Chrome Developer Tools

  1. Pingback: Chrome Web Inspector Web Socket Debugging | PHP Developer Resource

  2. Navtej Singh says:

    How does i’m getting response from echo.websocket.org. can i make it happen on my domain(linux server), if so, how ?

    ThanX

  3. You’ll need to have a WebSocket server running that your browser is connecting to.
    You can check out the WebSocket tutorial at http://tutorial.kaazing.com. For development purposes you can also download and install the Kaazing WebSocket Gateway for free.

  4. Nova S.J says:

    I am experimeting with web sockets.
    I look at http://www.websocket.org/echo.html site…
    There is simple echo demo for client [ Creating your own test ]

    It connects but can not able take response… Why? Should client work under a WebSocket supported Server?

  5. Pingback: Technologies shaping the Realtime Web (Part 1) « transformative paradigms

    • Depending on your location, network intermediaries (firewalls, routers, proxies) may block the traffic. The easiest way to address this is by using WebSocket secure (wss), instead of unencrypted WebSocket.
      Can you try checking the Use secure WebSocket (TLS) checkbox?

  6. Ananya says:

    Hi Nova, I face the same problem as you. Tried the same example as you have mentioned. Connection is opened, and client is able to send messages to server. But server messages are not received at the client side. Did you find any solution yet ?

  7. Philip Panicker says:

    Hi Peter,
    i tried websockets. i am able to send messages from server to client but after sometime client complains ‘Compressed bit must be 0 if no negotiated deflate-frame extension’ . what possibly can be the problem here? i guess my server messes the frame data by not setting the compressed bit(RSV1). .
    Can this be corrected from user side?

  8. Stephane says:

    Too bad we have to refresh the main panel manually by clicking on the echo.websocket.org entry on the left.

  9. Michael Joser says:

    I am having a problem where websocket echo test doesnt work with Chrome 64bit on my x64 computer. But trying it on my x32 computer all is fine.

    Another point is that ssl websocket works in x64

    • Thank you, Michael. I’m looking into this – will keep you posted! – Peter

      • brennangaunce says:

        Hi Michael – what specific platform are you using? (OS including version) What version of Chrome? (Check using chrome://version/ – first 3 lines) If you built it yourself, what steps did you use to build?

  10. Xiaoping says:

    it appear that the support of ‘x-webkit-deflate-frame’ is not quite right in the echo test page..
    And here is the reprodue:
    1). my server return this header: Sec-WebSocket-Extensions:x-webkit-deflate-frame to agree using deflate(http://tools.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-05.txt, in this draft, the register name is deflate-frame and i suppose it’s same to x-webkit-deflate-frame) and now this websocket connection established.
    2). i send first message from the test page, my server receives it and inflate it well.
    3). now my server echo back this message(deflates it as well)
    4). the page show the message correctly.
    5). i continue to send the same message, my server reject it due to failure happen in inflation

    i sneak thru wireshark and find the message sent from step 3) and step 6) are different in terms of length..

    • Xiaoping says:

      correct a typo:
      i sneak thru wireshark and find the message sent out from step 2) and step 5) are different in terms of length..

  11. Pingback: Chrome DevTools

  12. pk says:

    How can one specify the proxy info while establishing the websocket connection so that subsequent websocket traffic can go thru this proxy?

    I was under the impression that there will be CONNECT call displayed as part of the wss? But the headers are identical in ws and wss case? So how does the tunnel getting established as explained in wss section?

  13. Pingback: Inspecting WebSocket Traffic with Chrome Developer Tools | embeddist

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s