Ensuring user input isn't too large?

If you have a proxy/ballancer between world and your backend and you want to save CPU/bandwith on proxy (that is the better way) - you need to check request size on it - not on backend. If you don’t care about proxy - I’m not sure could it be accomplished on earler phases, but you can implement your custom websocket transport and check input message size before deserialization

You could do some validation on the client to check message size and whateverelse. This would elemenate a lot of failures. However, because of nature of JS, you would also want to implement your validations on the server to catch anyone trying to be sneaky. Something like the following should work.

def handle_in(msg, params, socket) do
  case validate_params(params) do
    :ok -> handle_message(msg, params, socket)
    {:error, reason} -> notify_failure(reason)
  end
end

defp handle_message("message 1", params, socket) do
  do_message_1(params)
end

...

This does let the message come in and get deserialized first though. I’m not sure if that is acceptable in your use case.

Actually the deserialization (means convert from JSON to map) happens at transport layer (as I mention above) and if we receive a-very-big packet of JSON we will get unnecessary CPU usage to convert it into map - so checks should be at very earler stages, ideally - at ballancer.

UPD Of course, you should check user input too (validate_params is necessary here), but the question was about message size as I understand

As you said, you’ll have to check at your load balancer or singular HTTP server. There is no way to check in the app layer where the deserialisation has already happened.

The actual deserialization (from stream of bytes into Elixir map) happens here. I agree that checks should be placed before backend but in case you have no control on ballancer - it’s at minimum saves CPU load for JSON deserialization of unnecessary packets.

In any case the size-check should be before deserialization and the user-input-check after

Phoenix depends on cowboy for HTTP and websockets, and cowboy has a feature to limit websocket frame sizes.

This commit from Nov 2018 exposed the max_frame_size setting in Phoenix. It’s in the master branch, but hasn’t made its way into a release yet.

That’s what I said. In my method, deserialization happens (the JSON is already an Elixir term). Yes this would waste cycles on larger payloads. However, with the validation, you wouldn’t waste cycles on invalid data (whether that be too large, incorrect shape, etc). I don’t know if it is the actual do_message_1 part that is also resource intensive, or they literally do not want to process large JSON inputs.

the handle_in callback called after the websocket transport decoding. And yes - the first argument for handle_in (the msg) is an elixir term, but it is a result of decoding byte-stream via Transport.decode!/2. So the size of packet of bytes should be checked there.

Or, better way as mentioned by @jmitchell - on cowboy level

I am agreeing with everything you have said. My option does not check size, as it is useless after the deserialization. Like I said, I don’t know if they wanted to literally reject a payload based on some size, or if they wanted to do some validations on the payload in order to prevent a resource intensive job from being started for known failures or something.

Very interesting answers, thank you everyone! So at loadbalancer/proxy level is best bet, but I’m not sure if the one I will be using eg. AWS or Digital Ocean can do that … unless I have another nginx at each node.

I guess doing both would be best.

I think maybe it would be good for phoenix to expose ability to set max request size for both websocket and http.

As for “complexity” of JSON object which might not correlate exactly to request size … I guess there isn’t really a way, other than validating afterwards.

Does websocket frame size mean the same thing as request size? I remember something about large requests being able to be separated into multiple frames, but I might be misunderstanding.