StompProtocolAndroid
StompProtocolAndroid copied to clipboard
Sending Large Payloads
Messages which are larger than 8k are now splitted into chunks.
The STOMP Specification says, concerning frame size limits:
To prevent malicious clients from exploiting memory allocation in a server, servers MAY place maximum limits on:
- the number of frame headers allowed in a single frame
- the maximum length of header lines
- the maximum size of a frame body
If these limits are exceeded the server SHOULD send the client an ERROR frame and then close the connection.
The spec also says, concerning frame structure:
The frame starts with a command string terminated by an end-of-line (EOL), which consists of an OPTIONAL carriage return (octet 13) followed by a REQUIRED line feed (octet 10). Following the command are zero or more header entries in
<key>:<value>format. Each header entry is terminated by an EOL. A blank line (i.e. an extra EOL) indicates the end of the headers and the beginning of the body. The body is then followed by the NULL octet.
In other words:
-
The STOMP Spec places no limits on frame size. There is no 8k limit on a STOMP frame. That is server-specific, and this generic library cannot enforce your personal configuration, especially at the expense of some other implementations -- which leads me to:
-
Your code splits STOMP frames up among multiple Websocket frames. This isn't exactly noncompliant with the spec, but it's not specified either. A number of STOMP brokers will allow this behavior, but others will not. So far, this library has made the assumption that 1 STOMP frame = 1 Websocket frame, which is the safest way to go.
So I think that if you want to allow chunking then you need to make the "chunk size" a configurable option in the StompClient, the same way that pathMatcher and legacyWhitespace are configurable there now. It needs to default to 0 or -1, meaning that there is no chunking.
Lastly, the chunking loop needs to be located in AbstractConnectionProvider.send rather than rawSend.
Good idea for splitting messages, but fully agreed with @forresthopkinsa - please make this option configurable and will be better to place chunking into AbstractConnectionProvider
Ok, thanks for the suggestions.