This doubt is actually derived from one of my questions about websockets... Differences between socket.io and websockets
I was thinking why web inspectors like google Chrome's/firebug/fiddler unable to trace messages while working with push technologies like websockets/channel-api, (or is there a way to do this?) Is this because we are upgrading our connection from http?
WebSockets is not using HTTP request. When you create WebSocket in JS, Browser creates TCP Socket connection to server and this connection is handled as stream based (because of TCP), when Browser receives enough data for single message it notifies WebSocket object using onmessage event passing through deframed data.
Technically it should not be difficult to implement own trace of all incoming messages and drop them in console. But beware that most of complex realtime applications that may use WebSockets have too much of data, that will slow down extremely your Inspector with sometimes hundred messages in a seconds.
IMHO, it is matter of time when major Browsers will implement WebSockets logging system with advanced filtering that will allow to show just necessary messages.
Fiddler does trace WebSocket messages, but as they aren't HTTP, they don't render in the Session list directly. See http://blogs.msdn.com/b/fiddler/archive/2011/11/22/fiddler-and-websockets.aspx
The answer to this post is out of date. As the writer stated, it was just a matter of time. Chrome has fairly good logging for WebSocket inspection nowadays
http://blog.kaazing.com/2012/05/09/inspecting-websocket-traffic-with-chrome-developer-tools/
