Closed phillip-haydon closed 9 years ago
Thanks for reporting this. The line you are referencing is indeed the culprit here. The SQS reference does require the items to be sorted when calculating the MD5 digest, but it appears this sorting should be case-sensitive. This issue will be fixed in the next update of the SDK.
We have just released version 2.3.24.3 of the SDK that resolves this issue.
Wow, wasn't expecting such a fast response! Thanks a lot @PavelSafronov <3 much love.
https://github.com/adamw/elasticmq/issues/13#issuecomment-77533445
I replied to an issue over at this ElasticMQ repo by mistake.
We are using the .NET SDK and have come across a problem with adding Attributes to messages. I can consistently reproduce this locally by creating messages with attributes that are keyed with lowercase and uppercase.
i.e
BANANA apple ZOO grape
The message will be accepted and placed on the queue. But reading the message back will result in a MD5 mismatch.
If I put invalid messages onto the queue, it prevents me from putting anymore on the queue that are valid. But also prevents me from reading the offending message from the queue.
This is the example I had.
The order of the attributes turns out to be different to the order they were added.
They were added in as
So I assume that the MD5 hash created on the client is different to the hash done via validation afterward.
https://github.com/aws/aws-sdk-net/blob/master/AWSSDK_DotNet35/Amazon.SQS/Internal/ValidationResponseHandler.cs#L143
Which happens to sort them.