When using WhatsApp web, when you send a message there are no requests showing up, but the message still delivers. Why are there literally no signs of any requests made in the networking tab??
And how to make it visible (if it's hidden)??
Note: It happens only on WhatsApp web. On other sites, it works and shows the GET and POST requests...
This is a common source of conufsion when debugging networking requests done from the web.
Normally, developers look at these network requests from top down and assume that the lowest one is the most recent request made - therefore assuming that the request must be at the bottom. For 'plain' HTTP this is correct. However, many apps that want to show data in real-time, use WebSockets to communicate with an API.
The same thing happens in the Web-version of Whatsapp. Only assets like the actual JavaScript-app, icons etc are loaded using plain HTTP. Then, a WebSocket is opened through which messages are exchanged for example.
To see the actual request do the following:
Open DevTools, go to networking tab
Open Whatsapp web. Make sure that at this step (1) is already recording!
Filter for "WS" in the filtering bar
There will be only very few results which you can click to investigate
Inspect this Socket using the 'messages' tab
Now send a message, you will see a message called binary message with your message as payload.
Try "Settings" -> "Preferences" -> "Network" -> "Record network log" in Chrome DevTools. This checkbox is probably unchecked in your situation. So, check it.
Otherwise if "Record network log" is checked, then try "Settings" -> "Preferences" -> "Restore defaults and reload".
So when I go to a website like, say https://coinmarketcap.com (that displays the prices of cryptocurrencies), in my Chrome Browser, it looks like I dont see all activity going on in the inspector under the Network tab.
Here is a screenshot to visualize the website:
I see the prices are updated live on the website (without refreshing), but I don't see any activity in the Network inspector.
There is of course activity when I load the page for the first time, but nothing after that even tho the website dynamically updates the prices? My firsts thought was, that it could be fake updates via a JS script on the client-side, but there are many websites I know where you can't see this, so what's going on here? What types of protocols are used to achieve this, because I know that WebSockets and polling (xhr) always shows up.
A screenshot of the network inspector, just be clear what I mean by that (showing traffic for the first 50 ms (loading time) and then nothing afterwards)
It using Web socket, you filter the request by WS and should see the latest ws connection.
Click on it and sees the message for this socket.
it was necessary to use a proxy like burpsuite in order to capture the sockets sent and received by the client / server here is the result it's about 72 request received in a single second
The website you suggested is using Websockets for communication.
To see WebSockets request in WS tab in Network inspector, You will have to open the console first then refresh the page.
The console needs to capture the initial handshakes when communication initializes. So if you open the website first then check the console, you may not find anything in WS.
I'm using an API on my website to send emails to the users and while testing my call I noticed I was receiving the email twice.
So the url looks like "localhost/api/sendEmail" and, at least on Chrome, when I'm on localhost and I start typing "/ap" the url is automatically completed.
And I can see on Fiddler that Chrome (well I think that's him) is actually calling it before I press Enter so the mail is sent, and when I press Enter it is of course sent a second time.
This is not a problem since it won't be directly callable by the end-user, but I was just wondering what is the purpose of this first call ? Is Chrome pre-calling the page to make it faster to load ? Can it cause problems in different situations? Can one prevent Chrome from behaving like this?
Again, not a problem at all, but I'm just wondering.
This is Google's prefetch feature, which loads the page quicker, assuming you execute the auto-completed URL.
You can disable this option in Google Chrome:
Settings > Advanced Settings > Privacy: (uncheck) Prefetch resources..
Update 2019
I came across a similar question on superuser, which I provided an updated answer for.
Disable page load prediction service
chrome://settings/ -> expand Advanced section
Disable NoState Prefetch
chrome://flags -> search for "nostate"
UPDATE: If I go back to 'All' tab and then back to 'XHR' I see both requests, so I guess it's some kind of chrome bug?
The GET request completes successfully but I cannot inspect the response. This occurs randomly in some of the endpoints of my api.
Firefox always logs the response.
You can always have a better view of the network communication via
chrome://net-internals/#events
Maybe you'll find something blocking it before reaching the dev tools..
On the network tab, you can remove the tick infront of this menu 3rd-party-request
Is there a way, or an extension, that lets me watch the "traffic" going through a WebSocket? For debugging purposes I'd like to see the client and server requests/responses.
Chrome developer tools now have the ability to list WebSocket frames and also inspect the data if the frames are not binary.
Process:
Launch Chrome Developer tools
Load your page and initiate the WebSocket connections
Click the Network Tab.
Select the WebSocket connection from the list on the left (it will have status of "101 Switching Protocols".
Click the Messages sub-tab. Binary frames will show up with a length and time-stamp and indicate whether they are masked. Text frames will show also include the payload content.
If your WebSocket connection uses binary frames then you will probably still want to use Wireshark to debug the connection. Wireshark 1.8.0 added dissector and filtering support for WebSockets. An alternative may be found in this other answer.
They seem to continuously change stuff in Chrome, but here's what works right now :-)
First you must click on the red record button or you'll get nothing.
I never noticed the WS before but it filters out the web socket
connections.
Select it and then you can see the Frames (now called Messages) which will show you error messages etc.
Chrome Canary and Chromium now have WebSocket message frame inspection feature. Here are the steps to test it quickly:
Navigate to the WebSocket Echo demo [dead as of 2022], hosted on the websocket.org site https://echo.websocket.events/.ws (run by the company Lob) or you can locally run the Echo Server project.
Turn on the Chrome Developer Tools.
Click Network, and to filter the traffic shown by the Dev Tools, click WebSockets.
In the Echo demo, click Connect. On the Headers tab in Google Dev Tool you can inspect the WebSocket handshake.
Click the Send button in the Echo demo.
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.
I also posted the steps with screen shots and video.
My recently published book, The Definitive Guide to HTML5 WebSocket, also has a dedicated appendix covering the various inspection tools, including Chrome Dev Tools, Chrome net-internals, and Wire Shark.
If you don't have a page which is accessing the websocket, you can open up the Chrome console and type your JavaScript in:
var webSocket = new WebSocket('ws://address:port');
webSocket.onmessage = function(data) { console.log(data); }
This will open up the web socket so you can see it in the network tab and in the console.
The other answers cover the most common scenario: watch the content of the frames (Developer Tools -> Network tab -> Right click on the websocket connection -> frames).
If you want to know some more informations, like which sockets are currently open/idle or be able to close them you'll find this url useful
chrome://net-internals/#sockets
You have 3 options: Chrome (via Developer Tools -> Network tab), Wireshark, and Fiddler (via Log tab), however they all very basic. If you have very high volume of traffic or each frame is very large, it becomes very difficult to use them for debugging.
You can however use Fiddler with FiddlerScript to inspect WebSocket traffic in the same way you inpect HTTP traffic. Few advantages of this solution are that you can leverage many other functionalities in Fiddler, such as multiple inspectors (HexView, JSON, SyntaxView), compare packets, and find packets, etc.
Please refer to my recently written article on CodeProject, which show you how to Debug/Inspect WebSocket traffic with Fiddler (with FiddlerScript). http://www.codeproject.com/Articles/718660/Debug-Inspect-WebSocket-traffic-with-Fiddler
If you want a better experience, I'd suggest using Postman to debug WebSocket requests. It has been released as a new feature.
https://stackoverflow.com/a/43754722/15988851
I'm just posting this since Chrome changes alot, and none of the answers were quite up to date.
Open dev tools
REFRESH YOUR PAGE (so that the WS connection is captured by the network tab)
Click your request
Click the "Frames" sub-tab
You should see somthing like this:
Chrome developer tools allows to see handshake request which stays pending during the opened connection, but you can't see traffic as far as I know. However you can sniff it for example.
Short answer for Chrome Version 29 and up:
Open debugger, go to the tab "Network"
Load page with websocket
Click on the websocket request with upgrade response from server
Select the tab "Frames" to see websocket frames
Click on the websocket request again to refresh frames
I have used Chrome extension called Simple WebSocket Client v0.1.3 that is published by user hakobera. It is very simple in its usage where it allows opening websockets on a given URL, send messages and close the socket connection. It is very minimalistic.
As for a tool I started using, I suggest firecamp Its like Postman, but it also supports websockets and socket.io.