Error when making a HTTP POST request to AWS

Questions
,
1

Describe the issue/error/question

I’m attempting to make a HTTP POST request towards AWS Gateway, but I keep getting a cryptic error I cannot figure out how to solve.

My AWS credentials are working, the URL is correct and everything seems to be configured correctly. The same request works when using Postman, however I might’ve missed something.

Would anybody have a clue what to try next?

What is the error message (if any)?

NodeApiError: UNKNOWN ERROR - check the detailed error for more information
    at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/HttpRequest.node.js:1035:27)
    at async Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/src/Workflow.js:619:28)
    at async /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/src/WorkflowExecute.js:557:53

Please share the workflow

Share the output returned by the last node

{
  "status":"rejected",
  "reason":
  {
    "context":{},
    "name":"NodeApiError",
    "cause":{},
    "timestamp":1664086235182,
    "message":"UNKNOWN ERROR - check the detailed error for more information",
    "node":
    {
      "parameters":
      {
        "authentication":"predefinedCredentialType",
        "nodeCredentialType":"aws",
        "requestMethod":"POST",
        "url":"https://xxx.amazonaws.com/api/thing",
        "allowUnauthorizedCerts":false,
        "responseFormat":"json",
        "jsonParameters":false,
        "options":{},
        "bodyParametersUi":{},
        "headerParametersUi":{},
        "queryParametersUi":{}
      },
      "id":"ad79e03f-d51f-4b58-9706-f7e7aa7d8716",
      "name":"HTTP Request",
      "type":"n8n-nodes-base.httpRequest",
      "typeVersion":2,
      "position":[460,300],
      "notesInFlow":true,
      "credentials":
      {
        "aws":
        {
          "id":"1",
          "name":"AWS account"
        }
      },
      "notes":"Get request ID"
    },
    "httpCode":null,
    "description":"Cannot read properties of undefined (reading 'replace')"
  }
}

The relevant part seems to be

Cannot read properties of undefined (reading 'replace')

Information on your n8n setup

  • n8n version: 0.195.5
  • Database you’re using (default: SQLite): default
  • Running n8n with the execution process [own(default), main]: default
  • Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker
2

Hey @Nurgak,

I suspect this is down to where the AWS credentials are a bit of a beast and we try to be clever when working out which endpoint to use and headers to set based on which AWS node is being used. When the HTTP request node is being used it doesn’t know which service is being used and hits the failure.

At the moment it would be a case of not using the predefined AWS credential until we fix this one or you could try adding a query string called “service” and setting the value to execute-api to see if that helps.

I have created an internal ticket for this which we will be tracking as N8N-4762

3

Thank you @Jon.

When I added the query parameter service, as you instructed, it changed the request URL. I got a different error message:

getaddrinfo ENOTFOUND execute-api.ap-northeast-1.amazonaws.comundefined

I thought I had to define the URL in the URL field… but this is a step further.

So I needed to define the service query parameter as xxx.execute-api. The suffix was set to undefined, most probably because I had not set the correct query parameter for that part.

I could not find documentation on how to set the last part of the URL, but digging through the code gave me the answer: it was path.

My request went trough successfully now, but what is the point of defining the URL, or perhaps this is just temporary?

4

Hey @Nurgak,

This is one of those things we overlooked when updating the AWS credentials recently, We have started talking on the ticket internally to work out the best way to handle this.

5

I found another issue with this node: when doing a POST request to AWS the body gets stringyfied (unless it’s a lamba service).

This means that there is no other method to submit the body than raw and then the data needs to be properly formatted so as to be ready to be immediately stringyfied.

For example, the following will fail:

  • test
  • {test: 1.0}

The following will pass:

  • "test"
  • {"test": 1.0}

It completely defeats the purpose of having Body Content Type set to anything else than raw, as this does not get properly parsed and leads to failed requests with cryptic error.
HTTP request node to AWS API Gateway

6

Hey @Nurgak,

Do you have an example of what you are sending? It looks like we only stringify the lambda calls but that looks to only be from the node itself and shouldn’t have any impact on the HTTP Request node.

7

Yes. In order to send a HTTP request to AWS API Gateway, one needs to define the following query parameters:

  • service: [xxx].execute-api
  • path: /[endpoint]

The HTTP request URL field is completely ignored in the request itself, however it cannot be empty in the node, so one can put a space there and it will pass the validation check. Behind the scenes the AWS request takes the region parameters from the AWS credentials and builds the URL such as:

https://[service].[region].amazonaws.com[path]

In the body, one cannot have anything but a valid raw stringyfiable JSON entry. So if I was to send a request to AWS API Gateway, the body parameters can be:

{"myParameter": [0, 1, 2], "another_parameter": {"sub_list": 1.5}}

If I was to send a binary or a simple unquoted string it would not work.

As an example, I sent test in the raw body, with a Content Type of text/plain:

400 - {"type":"Buffer","data":[123,34,109,101,115,115,97,103,101,34,58,32,34,67,111,117,108,100,32,110,111,116,32,112,97,114,115,101,32,114,101,113,117,101,115,116,32,98,111,100,121,32,105,110,116,111,32,106,115,111,110,58,32,67,111,117,108,100,32,110,111,116,32,112,97,114,115,101,32,112,97,121,108,111,97,100,32,105,110,116,111,32,106,115,111,110,58,32,85,110,114,101,99,111,103,110,105,122,101,100,32,116,111,107,101,110,32,92,39,116,101,115,116,92,39,58,32,119,97,115,32,101,120,112,101,99,116,105,110,103,32,40,74,83,79,78,32,83,116,114,105,110,103,44,32,78,117,109,98,101,114,44,32,65,114,114,97,121,44,32,79,98,106,101,99,116,32,111,114,32,116,111,107,101,110,32,92,39,110,117,108,108,92,39,44,32,92,39,116,114,117,101,92,39,32,111,114,32,92,39,102,97,108,115,101,92,39,41,92,110,32,97,116,32,91,83,111,117,114,99,101,58,32,40,98,121,116,101,91,93,41,92,34,116,101,115,116,92,34,59,32,108,105,110,101,58,32,49,44,32,99,111,108,117,109,110,58,32,53,93,34,125]}

The data part, converted to characters, translates to:

 '{"message": "Could not parse request body into json: Could not parse payload into json: Unrecognized token \\\'test\\\': was expecting (JSON String, Number, Array, Object or token \\\'null\\\', \\\'true\\\' or \\\'false\\\')\\n at [Source: (byte[])\\"test\\"; line: 1, column: 5]"}'
8

Hey @Nurgak,

Can you provide a workflow for both so we can see what you are doing this will make it a lot easier to reproduce the issue.

It sounds like there could be an issue with the v3 version of the HTTP Request node and not really related to the AWS file you linked to previously.

9

@Jon Oh yes, I misunderstood what “example” means.

Here’s one that works, notice the way contentType is set to raw:

Here’s a version that does not work, with contentType is set to JSON: