Logging WebSocket Frames using Chrome Developer Tools, Net-internals and Wireshark (TOTD #184)

Guest Author

#183 explained how to build a WebSocket-driven application
using GlassFish 4. This Tip Of The Day
(TOTD) will explain how do view/debug on-the-wire messages, or
frames as they are called in WebSocket parlance, over this upgraded
connection. This blog will use the application built in href="https://blogs.oracle.com/arungupta/entry/websocket_applications_using_java_jsr">TOTD

First of all, make sure you are using a browser that supports
WebSocket. If you recall from href="https://blogs.oracle.com/arungupta/entry/websocket_applications_using_java_jsr">TOTD
#183 then WebSocket is combination of href="http://tools.ietf.org/html/rfc6455">Protocol and href="http://www.w3.org/TR/websockets/">JavaScript API. A
browser supporting WebSocket, or not, means they understand your web
pages with the WebSocket JavaScript. href="http://caniuse.com/websockets"> caniuse.com/websockets
provide a current status of WebSocket support in different browsers.
Most of the major browsers such as Chrome, Firefox, Safari already
support WebSocket for the past few versions. As of this writing, IE
still does not support WebSocket however its planned for a future

Viewing WebSocket farmes require special settings because all the
communication happens over an upgraded HTTP connection over a single
TCP connection. If you are building your application using Java,
then there are two common ways to debug WebSocket messages today.
Other language libraries provide different mechanisms to log the

Lets get started!

Developer Tools
provide information about the initial
handshake only. This can be viewed in the Network tab and selecting
the endpoint hosting the WebSocket endpoint.


You can also click on "WebSockets" on the bottom-right to show only
the WebSocket endpoints.

Click on "Frames" in the right panel to view the actual frames being
exchanged between the client and server.

height="233" width="700">

The frames are not refreshed when new messages are sent or received.
You need to refresh the panel by clicking on the endpoint again.

To see more detailed information about the WebSocket frames, you
need to type "chrome://net-internals"
in a new tab. Click on "Sockets" in the left navigation bar and then
on "View live sockets" to see the page.

height="344" width="520">

Select the box with the address to your WebSocket endpoint and see
some basic information about connection and bytes exchanged between
the client and the endpoint.

height="320" width="700">

Clicking on the blue text "source dependency ..." shows more details
about the handshake.

height="625" width="685">

If you are interested in viewing the exact payload of WebSocket
messages then you need a network sniffer. These tools are used to
snoop network traffic and provide a lot more details about the raw
messages exchanged over the network. However because they provide
lot more information so they need to be configured in order to view
the relevant information.

Wireshark (nee Ethereal) is a
pretty standard tool for sniffing network traffic and will be used
here. For this blog purpose, we'll assume that the WebSocket
endpoint is hosted on the local machine. These tools do allow to
sniff traffic across the network though. Wireshark is quite a
comprehensive tool and we'll href="http://wiki.wireshark.org/CaptureSetup/Loopback">capture
traffic on the loopback address.

Start wireshark, select "loopback" and click on "Start".

height="584" width="731">

By default, all traffic information on the loopback address is
displayed. That includes tons of TCP protocol messages, applications
running on your local machines (like GlassFish or Dropbox on mine),
and many others. Specify "http" as the filter in the top-left.
Invoke the application built in href="https://blogs.oracle.com/arungupta/entry/websocket_applications_using_java_jsr">TOTD
#183 and click on "Say Hello" button once. The output in
wireshark looks like

height="303" width="700">

Here is a description of the messages exchanged:
  • Message #4: Initial HTTP request of the JSP page
  • Message #6: Response returning the JSP page
  • Message #16: HTTP Upgrade request

    height="357" width="700">

  • Message #18: Upgrade request accepted

    height="279" width="700">
  • Message #20: Request favicon
  • Message #22: Responding with favicon not found
  • Message #24: Browser making a WebSocket request to the

    height="393" width="700">

  • Message #26: WebSocket endpoint responding back

    height="446" width="712">

You can also use Fiddler
to debug your WebSocket messages.

How are you viewing your WebSocket messages ?

Here are some references for you:
  • JSR 356: Java API for WebSocket - href="http://websocket-spec.java.net/">Specification (href="http://jcp.org/aboutJava/communityprocess/edr/jsr356/index.html">Early
    Draft) and Implementation
    (already integrated in href="http://download.java.net/glassfish/4.0/promoted">GlassFish
    4 promoted builds)
  • href="https://blogs.oracle.com/arungupta/entry/websocket_applications_using_java_jsr">TOTD
    #183 - Getting Started with WebSocket in GlassFish

Subsequent blogs will discuss the following topics (not necessary in
that order) ...
  • Binary data as payload

  • Custom payloads using encoder/decoder
  • Error handling

  • Interface-driven WebSocket endpoint
  • Java client API
  • Client and Server configuration
  • Security
  • Subprotocols
  • Extensions

  • Other topics from the API

Join the discussion

Comments ( 1 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.