Empty message body fix

[jpalac]

Fix #1249

[danielmarbach]

Rebased and added some minor tweaks. Would it be possible to add one or two acceptance tests?

[jpalac]

Unfortunately found that Amazon SQS requires the MessageBody to have at least 1 character, so I have reverted back to using the "empty message" magic :-(

This will also make the decision document irrelevant.

[danielmarbach]

What if we did send {} instead? This would at least make some sense because the wrapper is json. We could byte encode this once and then always send that

[jpalac]

What if we did send {} instead? This would at least make some sense because the wrapper is json. We could byte encode this once and then always send that

Currently with the empty message, we don't base64 encode it, and then check for that string to also not decode it. If we get {}, couldn't that be a real value that is sent through by the user? In that case if they have encoding on, then we should be encoding it.

[danielmarbach]

I think the same argument could be applied to "empty message". So in essence, it boils down to saying there is a representation of an empty message that is not base64 encoded. That is essentially what the transport did, and I think we are now discussing what the better representation of an empty message is.

[jpalac]

Yes and we talked about it and thought that since we are already using "empty message" then keeping it this way is the path of least resistance in terms of wire compatibility.