Skip Menu | will be shut down on March 1st, 2021.

This queue is for tickets about the Amazon-SQS-Simple CPAN distribution.

Report information
The Basics
Id: 32766
Status: open
Priority: 0/
Queue: Amazon-SQS-Simple

Owner: swhitaker [...]
Requestors: swhitaker [...]

Bug Information
Severity: Normal
Broken in:
  • 0.1
  • 0.2
  • 0.3
  • 0.4
  • 0.5
Fixed in: (no value)

Subject: SendMessage fails when message contains UTF8 characters
Download (untitled) / with headers
text/plain 814b
Calling SendMessage with a message that contains UTF8 characters fails with this error: ERROR: On calling SendMessage: 401 Unauthorized (The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.) This is believed to be a bug in SQS - you can find numerous reports of similar bugs across a number of the Amazon Web Services in the AWS forums. In order to circumvent the bug, use SignatureVersion 0 (which does not use the message payload when calculating the signature) rather than SignatureVersion 1 (the default, which does). You can specify the signature version in the Amazon::SQS::Simple constructor: $sqs = new Amazon::SQS::Simple($access_key, $secret_key, SignatureVersion => 0);
From: swhitaker [...]
Download (untitled) / with headers
text/plain 191b
NB: the new release of SQS (2008-01-01) doesn't support SignatureVersion=0, so this workaround will no longer work. The SQS team at Amazon are aware of the problem and are working on a fix.
The problem is down to when/how the payload is encoded and the data which is used to calculate the md5 sum. Specifically that the payload is encoded with encode('utf-8-strict') but the unencoded payload is used in VerifyReceipt. This is how we've worked around it in our code: BEGIN { # Work around encoding/verification bug in Amazon::SQS::Simple::SendResponse. use Amazon::SQS::Simple::SendResponse; no warnings 'redefine'; no strict 'refs'; *{'Amazon::SQS::Simple::SendResponse::VerifyReceipt'} = sub { $_[0]->{MD5OfMessageBody} eq md5_hex(encode('utf-8-strict', $_[0]->{MessageBody})); }; } I'm not sure how you'll want to fix this in your own module hence why there's no patch included but I guess you may also want to make _escape_params do what it appears its supposed to be doing and return a new hash rather than changing values in-place. You may also want to consider using URI to perform the 2nd encoding of those values into the request URI rather than doing it by hand with uri_escape.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to