WebSocket frame length too large when requesting cached items

[ticky]

When requesting network responses which do not have a content-length, such as network responses returned from cache, the WebSocket response gives a ridiculous content-length (in this case, nearly a Petabyte - but it varies).

WebSocket connection to 'ws://192.168.7.82:9222/devtools/page/2' failed: WebSocket frame length too large: 898872230752645 bytes

As I can't see any code wherein ios-webkit-debug-proxy reads response headers, I can only presume that this is an issue with Safari's inspector WebSocket implementation, and that the limitation is suppressed when Safari sends data over USB.

This can be reproduced by following these steps;

1. Load any page which uses cachable resources (A web page using jQuery from Google's CDN is a good example)
2. Open the inspector (A) to monitor network requests
3. Open your browser's inspector (B) on the inspector page (A) which is pointed at the device
4. Reload the page
5. Click on the cached resource in inspector A (and note that the response headers do not include content-length)
6. Click "Preview" or "Response"
7. A WebSocket error such as the one above appears in the browser's error console (inspector B)

Is this likely to be something that can be fixed?

[npetkov]

I'm experiencing the same problem on Ubunutu 12.04 attaching an iOS 7 device. I finally managed to launch the debug proxy using libimobiledevice 1.1.6 and libusbmuxd 1.0.8, but when I try inspect a page on the device, I repeatedly get the same error mentioned above - WebSocket frame length too large. I tried using different devtools frontends, all to no avail. I don't have other iOS devices to test with right now, so I can't confirm this is related to iOS 7, however from comments around the web I suspect that this might not be the case as other users claim to be able to successfully inspect pages. Any help would be greatly appreciated.

[SamHasler]

I'm seeing this on an iOS6 device using the win32 port

[artygus]

the cause of the issue is incorrect websocket packets encapsulation that larger than 64kb
@SamHasler i just fixed the issue for win32 port

[artygus]

the issue seemed to affect 32bit machines only, see #150