backend/http allow setting custom success/failure HTTP codes for the http backend

[kvaidas]

Terraform Version

1.3.1

Use Cases

Some backends (like JFrog Artifactory) don't allow their users to control what exact HTTP code the server returns.

Attempted Solutions

It doesn't seem that currently there is any way around this.

Proposal

It would be useful to be able to specify success/failure HTTP codes for both state retrieval/upload and (un-)locking.

References

No response

[apparentlymart]

Hi @kvaidas,

According to some Artifactory documentation, Artifactory has first-class support for Terraform's remote backend to avoid all of the complexity of configuring the generic http backend against a generic Artifactory repository.

Have you tried to use that mechanism and found it doesn't meet your needs? I must admit I've not been able to try it myself yet (it's relatively new and I don't have an Artifactory install to test with) but I think it's best to treat the http backend as a last resort for unusual situations, and prefer to use first-class integrations where possible to reduce the client-side complexity.

[kvaidas]

Hi, @apparentlymart,

Sorry for the late reply. I can't use that functionality because the instance of Artifactory I'm currently using is not up to the version that has the Terraform functionality.
Having said that, even if at some point the instance does get upgraded and I get that functionality, it might be useful to have this feature for other cases.

[apparentlymart]

Thanks for sharing that additional context, @kvaidas!

The HTTP backend was originally intended as something with a fixed protocol on the client and then the user of it would write a tailored server to work with that protocol. It wasn't intended as a general client that can talk to arbitrary HTTP servers that have no awareness of Terraform.

Over time that design principle has become more muddled as we incrementally added new knobs and capabilities, and so I feel unsure about whether talking to a Terraform-unaware Artifactory is in this backend's scope.

The backend's scope already grew to include arbitrary request methods, and so I suppose it would be defensible to say that arbitrary status codes are also in scope since that is effectively the server-response equivalent of the client's request method.

However, this backend has already grown far beyond its original scope and has a large number of settings that make it very non-ergonomic to use, leading to very large backend "http" blocks covering various behaviors that would ideally be encapsulated into the server rather than duplicated into every configuration a team is using.

Ultimately this isn't my call to make but I personally feel pretty unsure about what direction to move here. Elsewhere we've been moving towards pushing the complexity into the server, such as how modern Artifactory encapsulates various details so that the remote backend configuration can be simple. However, the protocol for the remote backend isn't actually documented today, so anyone who wants to implement it would have to reverse-engineer it. I think we need to make a decision about where the concept of backends are going and in particular whether the path is towards specialized servers that can centralise the complexity (which would involve actually documenting a protocol for that) or whether it's towards allowing backends to live inside provider plugins so that they can cover all of the various different non-Terraform-aware servers without pushing all that complexity out into the leaf Terraform configurations.

🤔