WebSocket does not handle fragmentation or messages >1 MB, disconnects silently

The WebSocket implementaiton for the Chrome DevTools does not seem to handle either fragmentation (continuation frames) or messages that are larger than 1 MB in size.

This problem is reproducible after connecting to the webSocketDebuggerUrl of a page and either sending fragmented messages or messages above 1 MB in size.

In both cases the result is silent failure of the tcp connection. The error is found upon next write when the connection returns (among other things)write tcp 127.0.0.1:50872->127.0.0.1:9222: write: broken pipe.

I spent some time tracking down these two issues and came to the following conclusions:

1. Chrome does not support websocket fragmentation (continuation frames), they remain unimplemented at the time of writing (net/server/web_socket_encoder.cc#86)

2. The underlying HTTP connection does not support bigger payloads than 1MB, I believe the reason is the kDefaultMaxBufferSize, defined here: net/server/http_connection.h#33

   When we send messages larger than 1MB, Chrome logs the following:

   [89253:55299:0616/194024.005586:ERROR:http_connection.cc(37)] Too large read data is pending: capacity=1048576, max_buffer_size=1048576, read=1048576
   

The biggest use-case for this is probably sending large scripts over CDP, however, the current behavior does lead to hard-to-diagnose bugs. It would be nice if CDP could support WebSocket fragmentation, and at the very least provide useful error messages when it cannot handle a command.

Related issues:

• https://github.com/mafredri/cdp/issues/4
• https://github.com/gorilla/websocket/issues/245

[pavelfeldman]

I’m bumping it to a 100MB here - can’t do anything smart here since it needs to stay non-blocking.

[matthewmueller]

that’s wonderful news @pavelfeldman!

sorry late follow-up here, the large screenshots turned out to be a bug in my code. sorry for the false alarm and thanks for checking it out @mafredri!