application/octet-stream for yaml

[a0s]

Terraform Version

Terraform v0.14.8
provider registry.terraform.io/hashicorp/http v2.1.0

Affected Resource(s)

• data http

Terraform Configuration Files

data "http" "cert_manager" {
  url = "https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml"
}

output "content" {
  value = data.http.cert_manager.body
}

Debug Output

Warning: Content-Type is not recognized as a text type, got "application/octet-stream"

  on cert_manager.tf line 34, in data "http" "cert_manager":
  34: data "http" "cert_manager" {

If the content is binary data, Terraform may not properly handle the contents
of the response.

Expected Behavior

Should download yaml file

Actual Behavior

Shows warning and do nothing

Steps to Reproduce

1. terraform apply

Description

Pls remove limit on header for stream. As a modern repository jetstack/cert-manager (and many other repos) don't have released yaml inside repo thus it cant be accessed through raw.githubusercontent.com with right text headers.

[reallydontask]

The behaviour is actually very surprising as it will fail to update an existing data object if the url is changed from one that has appropriate headers to one that doesn't, which in my opinion is a bug

We had this data source, which was used to deploy the crds for cert-manager

data "http" "cert-manager-crds" {
  url = "https://raw.githubusercontent.com/jetstack/cert-manager/release-${replace(
    local.cert-manager-version,
    "/^v?(\\d+\\.\\d+)\\.\\d+$/",
    "$1",
  )}/deploy/manifests/00-crds.yaml"
}

it was then changed to this

data "http" "cert_manager" {
  url = "https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml"
}

I ran the plan and there was a warning about the content-type but when I tried to apply the plan, it failed as it had not applied the new crds.

[toabi]

In my experience it acutally downloads the file. But it's still annoying to get the warning for everything you download from github releases. Apparently everything from there is always this file type: mislav/hub#1966

[bendbennett]

@a0s, @reallydontask, @toabi 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.

[github-actions]

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.