Terraform HTTP provider handling request_body

Terraform
1

I have a use case, which I believe, is covered with the basic HTTP provider from Terraform, however I’m running in to what I think is just a formatting issue.

I am trying to POST a list of list values to a generic REST API with a couple of other required parameters. The working cURL for this looks like the below:

curl -k -u admin:pass https://url:port/working/uri -d 'field1=value1' -d 'field2=[[value2a], [value2b]]'

Trying a different end point to confirm what I know, I am happy with the format of the other fields, but after trying several permutations of what I expected Terraform to need, I’ve come up empty with the format for ‘field2’.

   request_body = {
    field1: "value1", 
    field2: "[['value2a'], ['value2b']]"
    }

Can anyone shed some light on how I should format field2?

2

Hi @skittles,

The useful information here is in the curl manpage for the -d option. Here are the relevant excerpts:

This option makes curl pass the data to the server using the content-type application/x-www-form-urlencoded.

If any of these options is used more than once on the same command line, the data pieces specified are merged with a separating &-symbol. Thus, using ‘-d name=daniel -d skill=lousy’ would generate a post chunk that looks like ‘name=daniel&skill=lousy’.

Using a mock API endpoint (I use Mockoon) passing your curl command (less the authentication elements as they are not relevant for this example) results in the following request being logged at the server:
image

The request_body attribute of the http resource requires a string.
The following Terraform:

data http http_example {
  url = "http://localhost:3000/mock"
  method = "POST"
  request_headers = {
    Content-type = "application/x-www-form-urlencoded"
  }
  request_body = "field1=value1&field2=[[value2a], [value2b]]"
}

Results in the same request format at the server:

image

Hope that helps.

Happy Terraforming!

4

@rtwolfe - the OP is not trying to post a JSON body, but a form encoded body with an existing API they may not have the capability or desire (especially if it is third-party or downstream from other consumers which would also need changing) to refactor in order to accept a json encoded body as you suggest.

AI/CoPilot tools (as you have used for answering numerous posts) are great tools and often present comprehensive and seemingly viable answers. But the answers do need validating in light of the context of the requirements (as is this case) and also for accuracy / validity overall in case of hallucination and other artefacts.

5

Indeed, I would suggest that those who wish to use large language models as an aid to answering their questions do that directly and interpret the results privately for themselves, rather than sharing them as answers in this forum.

While they can sometimes be helpful, folks who are participating in this forum are presumably hoping to interact with humans sharing their direct experiences and knowledge, rather than (indirectly) with chatbots or similar. Those who wish to make use of language models can do so directly (and thus try to tailor the responses to their situation with additional clarifying prompts).

I do imagine that this was a good-faith attempt to help participants in this forum but I would request that it not become routine for topics in this forum to have machine-generated responses posted to them. This is primarily a person-to-person forum. Thanks!

1 Like
6

Ok I will leave the forum thanks

7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.