RFC 6455, section 1.2 says:
The WebSocket message does not necessarily correspond to a particular network layer framing, as a fragmented message may be coalesced or split by an intermediary.
Section 10.4 addresses implementation-specific limits:
Implementations that have implementation- and/or platform-specific limitations regarding the frame size or total message size after reassembly from multiple frames MUST protect themselves against exceeding those limits. (For example, a malicious endpoint can try to exhaust its peer’s memory or mount a denial-of-service attack by sending either a single big frame (e.g., of size 2**60) or by sending a long stream of small frames that are a part of a fragmented message.) Such an implementation SHOULD impose a limit on frame sizes and the total message size after reassembly from multiple frames.
Section 5.2 shows that frames have a FIN bit which:
Indicates that this is the final fragment in a message. The first fragment MAY also be the final fragment.
Fields about payload length only pertain to one frame/fragment. To determine the length of the message the receiver must consume frames until reaching one where FIN == 1 and then sum the payload lengths of all those fragments. Given the concern raised in 10.4 about malicious endpoints, an implementation shouldn’t actually concatenate all the fragment payloads into a message if it would exceed the implementation-defined limit; otherwise, it would have to temporarily store an arbitrarily long sequence of potentially large payloads.
After reading some of the cowboy code I think max_frame_size applies both to individual frames and the accumulated payloads from a sequence of fragments for the same message.
Fair warning: I haven’t tested it, and I only recently started reading this code.
!!