Bad request with when creating cloudflare_api_shield_schema resource

[harrydowe]

Confirmation

• This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.10.5
on darwin_arm64

• provider registry.terraform.io/cloudflare/cloudflare v5.1.0

Affected resource(s)

• cloudflare_api_shield_schema

Terraform configuration files

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5.1"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

resource "cloudflare_api_shield_schema" "example_api_shield_schema" {
  zone_id = var.cloudflare_zone_id
  file = jsonencode({
    "openapi" : "3.0.3",
    "info" : {
      "title" : "Example",
      "version" : "0.1.0"
    },
    "servers" : [
      {
        "url" : "api.example.com"
      }
    ],
    "paths" : {
      "/" : {}
    }
  })
  kind               = "openapi_v3"
  name               = "example_schema.json"
  validation_enabled = "true"
}

Link to debug output

https://gist.github.com/harrydowe/fb2a163ce6a1cb33a2ca90342b275a83

Panic output

No response

Expected output

I expected the cloudflare_api_shield_schema resource to be created successfully.

Actual output

The resource was not created and produced a 400: Bad Request error.

Steps to reproduce

1. Create an empty directory containing main.tf with the provided configuration
2. Supply relevant Cloudflare authentication and zone ID variables
3. Run terraform apply -auto-approve

Additional factoids

Looking at the logs, I belive the issue is due to the Content-Disposition header missing the filename directive:

--86a74be2fefb2b7a2b1239eb82aac9a05e6e26c66c5209734602cece8eb9
Content-Disposition: form-data; name="file"

<file_contents>

I think it should include the filename directive:

--86a74be2fefb2b7a2b1239eb82aac9a05e6e26c66c5209734602cece8eb9
Content-Disposition: form-data; name="file"; filename=openapi.json

<file_contents>

I'm able to successfully perform the request when using Postman and correctly selecting the file form param to be File instead of Text. I can also perform the request in my PHP application using curl (Guzzle) and specifying the filename for the file multipart form param. Omitting this causes a 400 error.

Related guzzle code
https://github.com/guzzle/psr7/blob/2.7/src/MultipartStream.php#L127

References

No response

[janrueth]

I can confirm the bug. The system expect a non-empty filename as part of the Content-Disposition header for the file upload. The existence of a non-empty filename header is also how e.g., golang's stdlib multi-part parser differentiates files from plain string values.

I guess the issue here is that there is no way to declare that filename header via terraform.

The file attribute of the multi-part request body on that API endpoint is marked as format: binary: https://developers.cloudflare.com/api/resources/api_gateway/subresources/user_schemas/methods/create/
Which is how OpenAPI describes to identify file uploads: https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.2.md#considerations-for-file-uploads

For the particular system that implements this API endpoint, any non-empty filename header would work as it will honor the name attribute and only fallback to the filename header if name is not provided.

[jacobbednarz]

i've got a fix for the multipart filename missing however, fixing that has uncovered that this schema isn't really that usable. i'll have a chat with the internal team about what we want to do to fix it.