[GiuseppeSaluto]

Closes #43

This adds a :max_message_size option to Mint.WebSocket.new/5. When an incoming message goes over the limit, decode/2 returns {:error, websocket, %Mint.WebSocketError{reason: :message_too_large}}.

{:ok, conn, websocket} =
  Mint.WebSocket.new(conn, ref, status, headers, max_message_size: 1_048_576)

Where the limit is enforced

1. Frame header: a frame whose declared payload length is over the limit is rejected as soon as the length is read, before any payload gets buffered.
2. Fragmented messages: the accumulated size of the fragments is checked in combine/3, before concatenating.
3. permessage-deflate: :zlib.inflate/2 is replaced by a :zlib.safeInflate/2 loop that checks the inflated size after each chunk and stops as soon as it goes over the limit. A small compressed message can no longer inflate into an unbounded binary.

All three use the same check (Frame.check_message_size/2) and return the same error. The limit reaches PerMessageDeflate through the extension's opts, so the Extension behaviour is unchanged.

Default (breaking change)

As discussed in #43, the default is 8_000_000 bytes (same as Plug.Parsers), with :infinity to opt out. Users receiving messages larger than 8 MB need to set the option, e.g. max_message_size: :infinity. This is visible in the Autobahn suite: cases 9.1.5/9.1.6/9.2.5/9.2.6 send 8 and 16 MiB messages, so the test client now passes :infinity.

If you'd rather keep :infinity as the default to avoid the breaking change, it's a one-line change in @default_max_message_size.

Known limitations

• Inflation overshoot: the inflated size is checked after each safeInflate chunk, so up to one chunk (16 KB on OTP 27) may be inflated past the limit before stopping.
• Compressed frames near the limit: the header check uses the frame's (compressed) payload length. For incompressible data, the compressed frame can be a few bytes larger than the original message, so a message within a few bytes of the limit may be rejected.
• No validation of the option value, consistent with :mode. Happy to add a check if you'd like.

Tests

New tests in test/mint/web_socket_test.exs, with a 100-byte limit:

• a frame declaring a 4 GB payload is rejected from its header;
• a fragmented message over the limit (60 + 60 bytes) is rejected, and one exactly at the limit (60 + 40) is delivered;
• a compressed message inflating over the limit (1,000 bytes, compressed under 100) is rejected, and one inflating exactly to the limit is delivered (against the local Cowboy server with compression).

mix test (including Autobahn), mix dialyzer, mix format --check-formatted and mix compile --warnings-as-errors all pass locally.

[whatyouhide]

Control frames: the header check also applies to ping/pong/close frames (up to 125 bytes), so a limit below 125 bytes could reject them.

Should we consider setting up a minimum limit that prevents things like these happening?

[GiuseppeSaluto]

Hello @whatyouhide!
We could opt for a minimum value: new/5 would raise an ArgumentError. Unless :max_message_size is either :infinity or an integer ≥ 125 (which is the maximum payload for control frames according to RFC 6455). This ensures that ping, pong, or close frames can never reach that limit. I can also update the typespec and the documentation, and add a test case.

[GiuseppeSaluto]

Hello @whatyouhide
Pushed: new/5 now raises ArgumentError unless :max_message_size is :infinity or an integer >= 125. Updated the typespec and docs, and added a test. Existing tests now use a 200-byte limit.