Sorry for the late response and thank you for your time and effort to provide us with the RawCap output. I examined the traffic and I realized that I need some more information before I can reproduce the issue.
Firstly, I would like to explain in general how a WebSocket Connection is established via an HTTP proxy like Fiddler to make sure that we are all on the same page.
When the client is configured to use an HTTP proxy and it wants to establish a WebSocket connection with a server, firstly it opens a TCP connection to the proxy and sends an HTTP CONNECT request to the proxy. The request contains the hostname and the port of the server. Then the proxy opens a TCP connection to the server on the specified port. After this, the proxy responds to the client with 200 Connection established and it keeps both TCP connections (to the client and the server) open. Now the proxy is expected to forward the bits flowing in these TCP connections which creates a tunnel between the client and the server.
Now the client knows that it can communicate with the server and it sends HTTP GET request with a Connection:Upgrade and Upgrade: websocket headers and the server responds with HTTP 101 status code which means that they have just upgraded to the WebSocket protocol. Please, note that I am purposely skipping the WebSocket handshake requirements to keep this post focused.
In your pcap file I could not find the HTTP CONNECT request from the client to the proxy. Then I remembered that RawCap can sniff only one network interface at a given time and I realized that you were sniffing your Ethernet network interface. However, your client app and Fiddler communicate on the Loopback pseudo-network interface, which I believe you did not sniff in this pcap file.
Could you, please, make another sniff, this time on the loopback interface. Could you, please, also let me know if you see a "Tunnel to" session in Fiddler for the WebSocket connection. If there is no such session most probably your client is not configured to use the system proxy (WinINET) which Fiddler sets by default. It is possible that your client goes direct to the server or it could use a SOCKS proxy which Fiddler currently does not support.
You could examine the pcap to check if there is any communication between the client and Fiddler. You can add this to your C# FiddlerScript:
public static string FillClientPortColumn(Session session)
Which will make a 'Client port' column in the Fiddler's Session list and you will be able to get the port which your app uses to communicate with Fiddler. Then in the pcap file look for packets with that port as destination or source port and 8888 (the default Fiddler listen port) as the source/destination port.
And finally, if you could provide us with some demo app and server and source code to reproduce the issue this would be great.
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Feedback Portal
and vote to affect the priority of the items