fix: Check the max data size against the final message payload #212
Conversation
| @@ -33,6 +24,17 @@ pub fn build_message_data( | |||
| Ok(message_data) | |||
| } | |||
|
|
|||
| /// Check the data against the max data size and return an error if there is too | |||
| /// much data. | |||
There was a problem hiding this comment.
Kind of depends on how you want to do this, but for the python side, I determined that the max payload size depends on the encoding type. aesgcm requires the header keys, which need to be included with the overall payload and impact the size of the data that can be sent over. aes128gcm includes the decryption keys in the body payload, and the body and therefore the body can be larger. The other problem is that the body is base64 encoded which basically inflates things by about 1.3x, which may confuse update publishers that don't know that.
Of course, key sizes can vary as can the result of base64 encoding, so things are bit fuzzy as far as how big things are or could get.
There was a problem hiding this comment.
The payload size error returns the number of excess bytes, so the publishers will have an idea about how much data to cut out. I feel like doing the fuzzy calculations of guessing the raw data size and accounting for base64 adds a lot of unnecessary complexity/uncertainty and is too hand-holding. We should view this from the perspective of the messaging services (like FCM) and just make sure the data we are passing along will fit through the bridge services. If it doesn't fit, then we relay the excess byte count to the publisher. We can talk about this in the docs so the publishers have more insight into why they might be over the payload limit, but guessing the reason in code seems error-prone.
There was a problem hiding this comment.
I suppose putting a note in the docs might be as useful. One thing I've discovered is that the more data you can put into error messages, the less customer support and invalid bug triage you have to do in the future. Folks are less inclined to read docs than error messages, but at least we can point them in the right direction.
Related to mozilla-services/autopush#1430
Fixes #203