Question: When using Perl's [Websocket server](http://search.cpan.org/~topaz/Net-WebSocket-Server-0.001003/lib/Net/WebSocket/Server.pm), if I send a json message using send\_utf8 that's longer than about 16,000 characters, it causes the connection to the websocket to be killed in Chrome with the message:

"Could not decode a text frame as UTF-8".

Is there some restriction on the length of messages that can be sent by this Websocket server, and is there a way of getting around this restriction?

Answer: 
Apparently, it's possible to set the payload size in the Protocol::WebSocket::Frame constructor (<https://github.com/vti/protocol-websocket/issues/24#issuecomment-27095561>).

Unfortunately the docs on cpan seem to be missing that information.

Try this:

```
$hs->build_frame(buffer => $my_data, max_payload_size => 200000)->to_bytes);

```
I think that the size of the outgoing message is in fact not the problem. I have the same exact issue and setting the "max\_payload\_size" to a larger value does not solve it. If this were the problem you would see the error message from the Frame.pm "to\_bytes" sub "Payload is too big. Send shorter messages or increase max\_payload\_size". When I send a message from the server to Chrome over 16k I do not see this error (or any other) on the server, yes I still get the "Could not decode a text frame as UTF-8" with an "(Opcode -1)" as the frame message body highlighted in red in the Chrome inspector network tab.

I think it is far more likely that this is a IO::Socket::SSL issue, as I am using it as prescribe in the Net::WebSocket::Server docs. I am curious if you are well, or if you see this problem in regular un-uncrypted sockets.

From the IO::Socket::SSL Docs:

> 
> syswrite( BUF, [ LEN, [ OFFSET ]] ) This functions behaves from the
>  outside the same as syswrite in other IO::Socket objects, e.g. it will
>  write at most LEN bytes to the socket, but there is no guarantee, that
>  all LEN bytes are written. It will return the number of bytes written.
>  syswrite will write all the data within a single SSL frame, which
>  means, that no more than 16,384 bytes, which is the maximum size of an
>  SSL frame, can be written at once.
> 
> 
> 

Net::WebSocket::Server::Connection is calling syswrite after the frame is built:

```
syswrite($self->{socket}, $bytes);

```

Any ideas how to deal with this I am curious about. Perhaps the Frame module should fragment messages below 16k when using SSL, but that would have to be handled in Connection.pm I would think.

UPDATED with solution:

it turns out this is a pretty easy fix if you are willing to modify the Connection.pm and put the syswrite into a 16k loop. Remembering that SSL Frames and WebSocket Frames are not the same thing, we just need to not overflow the SSL frame size. See working solution:

```
sub send {
  my ($self, $type, $data) = @_;

  if ($self->{handshake}) {
    carp "tried to send data before finishing handshake";
    return 0;
  }

  my $frame = new Protocol::WebSocket::Frame(type => $type, max_payload_size => $self->{max_send_size});
  $frame->append($data) if defined $data;

  my $bytes = eval { $frame->to_bytes };
  if (!defined $bytes) {
    carp "error while building message: $@" if $@;
    return;
  }

  # modified to not overflow the 16k SSL frame size
  while( 16384 < length $bytes ) {
    syswrite( $self->{socket}, $bytes, 16384 );
    substr( $bytes, 0, 16384, '' );
  }
  syswrite($self->{socket}, $bytes);
}

```

I was able to send a 27k json string back to Chrome that had previously not worked over SSL.