Conditional request headers

Edit online

When making a request to read or write data, it is possible to set conditions on that request to avoid unnecessary operations. This is accomplished using pre-conditional HTTP headers:

If-Match
If-None-Match
If-Modified-Since
If-Unmodified-Since

Note: It is generally preferable to use If-Match because the granularity of the Last-Modified value is only in seconds, and may not be sufficient to avoid race conditions in some applications.

Header	Type	Description
`If-Match`	string	On an object PUT, HEAD, or GET request, the `If-Match` header will check to see if a provided `Etag` (MD5 hash of the object content) matches the provided `Etag`value. If this value matches, the operation will proceed. If the match fails, the system will return a 412 Precondition Failed error. `If-Match` is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem).
`If-None-Match`	string	On an object PUT, HEAD, or GET request, the `If-None-Match` header will check to see if a provided `Etag` (MD5 hash of the object content) matches the provided `Etag` value. If this value does not match, the operation will proceed. If the match succeeds, the system will return a 412 Precondition Failed error on a PUT and a 304 Not Modified on GET or HEAD. `If-None-Match` is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum amount of transaction overhead. When a client desires to update one or more stored responses that have entity-tags, the client SHOULD generate an `If-None-Match` header field containing a list of those entity-tags when making a GET request; this allows recipient servers to send a 304 (Not Modified) response to indicate when one of those stored responses matches the selected representation.
`If-Modified-Since`	string	On an object HEAD or GET request, the `If-Modified-Since` header will check to see if the object's Last-Modified value (for example Sat, 14 March 2020 19:43:31 GMT) is newer than a provided value. If the object has been modified, the operation will proceed. If the object has not been modified, the system will return a 304 Not Modified. `If-Modified-Since` is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed.
`If-Unmodified-Since`	string	On an object PUT, HEAD, or GET request, the `If-Unmodified-Since` header will check to see if the object's Last-Modified value (for example Sat, 14 March 2020 19:43:31 GMT) is equal to or earlier than a provided value. If the object has not been modified, the operation will proceed. If the Last-Modified value is more recent, the system will return a 412 Precondition Failed error on a PUT and a 304 Not Modified on GET or HEAD. `If-Unmodified-Since` is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the selected representation does not match one already stored (or partially stored) from a prior request.