If-Match HTTP request header makes the request conditional. For
HEAD methods, the server will send back the requested resource only if it matches one of the listed
PUT and other non-safe methods, it will only upload the resource in this case.
The comparison with the stored
ETag uses the strong comparison algorithm, meaning two files are considered identical byte to byte only. If a listed
ETag has the
W/ prefix indicating a weak entity tag, it will never match under this comparison algorithm.
There are two common use cases:
HEADmethods, used in combination with a
Rangeheader, it can guarantee that the new ranges requested comes from the same resource than the previous one. If it doesn't match, then a
416(Range Not Satisfiable) response is returned.
If-Matchcan be used to prevent the lost update problem. It can check if the modification of a resource that the user wants to upload will not override another change that has been done since the original resource was fetched. If the request cannot be fulfilled, the
412(Precondition Failed) response is returned.
If-Match: <etag_value> If-Match: <etag_value>, <etag_value>, …
"675af34563dc-tr34"). They may be prefixed by
W/to indicate that they are "weak", i.e. that they represent the resource semantically, but not byte-for-byte. However, in an
If-Matchheader, weak entity tags will never match.
If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d" If-Match: "67ab43", "54ed21", "7892dd" If-Match: *
|RFC 7232, section 3.1: If-Match||Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests|
Range Not Satisfiable
© 2005–2020 Mozilla and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.