[feature] Max send frame size

[tigrannajaryan]

Problem Description

Some WebSocket implementations have trouble receiving large frames. Fir example AWS API Gateway cannot receives frames larger than 32KB.

When sending large messages to such implementations the sending typically fails since gorilla websockets do not normally slice large messages and send them as one frame.

Possible Solution

It would be great to add an option to specify the maximum frame size in the client and in the server. We already have WriteBufferSize which when sending small messages acts as the frame size limit (we accumulate messages up to WriteBufferSize bytes and send them in one frame).

A WriteMaxFrameSize option would be a nice addition to the Dialer and Upgrader. The WriteMessage and NextWriter.Write calls would honour the WriteMaxFrameSize setting.

Alternate Solution

Currently if you use NextWriter.Write you can control the frame size to some degree. This is because NextWriter.Write sends the frame as soon as the write buffer is full. So, by setting a desired WriteBufferSize one can slice the payload in the application and then repeatedly call NextWriter.Write calls to make sure each portion is delivered as a separate frame.

This is however undocumented implementation detail. An alternate solution would be document this behavior and explain how one can use it to control the frame size.

[ghost]

We need more than one frame per message when sending a large message to AWS. We need exactly one frame per message when sending a compressed message to Safari. What a world we live in!

I took a look at the code. You should be good with multiple write calls as a workaround for this issue.

[tigrannajaryan]

I took a look at the code. You should be good with multiple write calls as a workaround for this issue.

@volkerite yes, I did check the code and that's how it works currently. However, as far as I can tell this specific behavior is not documented. If it is expected that this is how NextWriter.Write should work then it would be great to have this documented so that I can rely on it.

[ghost]

An alternative to MaxFrameSize is to add a Flusher interface to package and support that interface on writers.

type Flusher interface {
	// Flush sends any buffered data to the client.
	Flush() error
}

Applications can limit frame size by flushing as appropriate.

I am not convinced that Flusher is better than OP's MaxFrameSize proposal. I am just throwing this out for consideration.