I am new to Terraform and wanted to ask a couple of questions related to state locking. I was reading "http" backend documentation (https://developer.hashicorp.com/terraform/language/settings/backends/http#unlock_method) and have a couple of questions.
First, it is not clear for me what is the purpose of lock_address and unlock_address endpoints ? Do I understand correctly that when request is made to lock_address endpoint the state gets locked and after applying changes to the state there needs to be made the request to unlock_address to unlock the state ?
Secondly, there exists lock_method and unlock_method arguments and these methods default to LOCK and UNLOCK . Are these methods the HTTP request methods when making request to lock and unlock addresses ? Why are they not from the traditional HTTP request methods (like GET,PUT,POST,DELETE, etc.) ?
If lock_address and unlock_address are intended for sate locking and unlocking so the state stays locked for as long as the unlock_address endpoint is not called ?
The "http" backend is unusual compared to the others in that it has very few opinions of its own and instead tries to be flexible to be able to work with a variety of different server implementations.
For a full understanding of how it interacts with the specified URLs and methods you may wish to refer to the backend's remote state client implementation, which shows how each of Terraform's state manager operations relates to the backend configuration.
Some highlights from that related to your questions:
When Terraform wants to lock the state, the client sends a request to the lock URL using the lock method.
For example, if you configure the lock method as LOCK (which is the default) and the lock URL as https://example.com/ then the client will send a LOCK / request to the HTTPS server for example.com.
Similarly, when Terraform wants to later unlock the state the client does a similar request using the unlock settings.
For example, if you configure the lock method as UNLOCK (which is the default) and the lock URL as https://example.com/ then the client will send a UNLOCK / request to the HTTPS server for example.com.
The behavior Terraform is expecting when it makes these requests is that the server will remember that there has been a lock request and not yet been an unlock request. If another client makes a lock request while that is true, the server must respond to the second lock request with an error.
When returning such an error, the backend's client expects the response error code to either be 409 Conflict or 423 Locked, which the client treats as synonyms for this situation.
The default method names and error response assumptions made by the backend for locking are intended to be compatible with RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV), although this is not a full client implementation of that standard, instead just borrowing the subset relevant to locking to avoid specifying something completely custom to Terraform.
However, the backend allows you to reconfigure the lock and unlock methods so that you can instead use other conventions if you prefer to. For example, you can choose to set lock_method and unlock_method both to POST and use different URLs to distinguish them, if that better suits the technology you are using to implement the server. The 423 Locked response status is also part of the WebDAV specification, and so Terraform also supports the base-HTTP-only 409 Conflict as a synonym, to support implementing servers that don't use any of WebDAV's extensions.