terraform-provider-http

terraform-provider-http copied to clipboard

Given a URL that serves application/zip content (or some other archive content), I would like to be able to reference it in other resources that require it (see example below). I poked around the http or the archive providers and noticed that the http provider came the closest to this, but it doesn't handle application/zip content based on the docs:

At present this resource can only retrieve data from URLs that respond with text/* or application/json content types, and expects the result to be UTF-8 encoded regardless of the returned content type header.

It would be nice to be able to reference remote archive types and use them for resource that require archive types.

See example configuration below.

Terraform Version

Terraform v0.11.7 locally, but using Terraform Enterprise as well.

Affected Resource(s)

• data.http

Terraform Configuration Files

Example:

data "http" "foobar-zip" {
     url = "http://location.to.zip/foobar.zip"
}

resource "aws_lambda_function" "lambda-foobar" {
  function_name    = "lambda-foobar"
  handler          = "com.foobar::FooBar"
  role             = "lambda-role"
  runtime          = "java8"
  filename         = "${file(data.http.foobar-zip)}"
  source_code_hash = "${base64sha256(file(data.http.foobar-zip))}"

  depends_on = [
    "data.http.foobar-zip",
  ]
}

Debug Output

Content-Type is not a text type. Got: application/zip

Expected Behavior

Fetches bytes of the zip and references them as the file for the lambda.

Actual Behavior

It fails the plan with the Debug Output listed above

Relevant Issues

• https://github.com/hashicorp/terraform/issues/6513

@dotCipher it seems that content-types that are not recognised as text have been "allowed" since v2.0.0 in that if the content-type is not identified as text then a warning is issued but the body (or response_body since v2.2.0) should still be populated with a string representation of the response body.

There is an open #158 to include an additional attribute, response_body_base64_std which is intended to hold a standard base64 encoding of the response body. Additionally, a warning will only be issued if the response body is not valid UTF8.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.