- 最新
- 投票最多
- 评论最多
I had a similar case. like the above response, i'm using API Gateway as service proxy to send a message to SQS.
I was able to resolve this by applying a util on the $input.body
In my case i rewrite the request template as one of the following (depending on how you want to consume it later from SQS):
application/json: "Action=SendMessage&MessageBody=$util.urlEncode($input.body")
OR
application/json: "Action=SendMessage&MessageBody=$util.base64Encode($input.body")
See this reference: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html
I was able to isolate the issue. A field contained an ampersand "&" in the message being put into body. changing ampersands to "and" in the DB and that did the trick...not sure why this was an issue, or if this was ultimately the final cause (it could be the 3rd parties webhook that sends the initial message doesn't handle the ampersand well). That would be my first guess but I do not have the time to dig any further or point test SQS to find out!
相关内容
- AWS 官方已更新 4 个月前
- AWS 官方已更新 8 个月前
- AWS 官方已更新 1 年前
- AWS 官方已更新 5 个月前
Excellent response! This is the preferred way to handle this. The link reference is a great place to start to resolving some of these input source anomalies. urlEncode() and base64Encode() are great suggestions.