API Gateway Rest Endpoint "MalformedQueryString" (worked prior for 1 month)

0

Hi, I have had an API gateway running as a webhook receiver -> SQS for a little over a month with no issues. As of 9/26, I started receiving an error on all requests on my only endpoint for this API two days ago.

{
    "Error": {
        "Code": "MalformedQueryString",
        "Message": "Keys may not contain  ",
        "Type": "Sender"
    },
    "RequestId": "XXXXX"
}

This is the end points def in template.

    responses:
      default:
        statusCode: "200"
    requestParameters:
      integration.request.header.Content-Type: "'application/x-www-form-urlencoded'"
    requestTemplates:
      application/json: "Action=SendMessage&MessageBody=$input.body"
    passthroughBehavior: "never"
    type: "aws"

Issue I am having is that the message body to the API is always truncated, with no discernable difference in the first 1024kb of the data with historical vs new messages that are failing. I can only assume after the first 1024kb of data, there must be a difference in the message being received? How do I troubleshoot this further?

2 réponses
0
Réponse acceptée

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

répondu il y a 10 mois
  • 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.

0

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!

répondu il y a 2 ans

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions