For my REST API design I am allowing the ability to modify (PUT, DELETE) resources using If-Match conditional header to avoid the Lost Update Problem. This is similar to what is described here: https://www.kennethlange.com/avoid-data-corruption-in-your-rest-api-with-etags/
However, I know that there are 4 conditional headers (If-Match, If-None-Match, If-Modified-Since, and If-Unmodified-Since). Will it be OK to ignore or disallow the If-Modified* and If-UnModified headers? is that standard or not?
I decided ETags would be more reliable measure to check the record has been updated. Using datetime in other conditional headers is not reliable and I don't think is needed.
So is it ok to only use If-Match and If-None-Match headers? and if so, do I simply ignore other headers or can I return 400 Bad request?
So is it ok to only use If-Match and If-None-Match headers? and if so, do I simply ignore other headers or can I return 400 Bad request?
I believe the answer is found in RFC 7230:
A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics.
My reading of the standard is that you are allowed to ignore extensions, but I don't see any text that allows you to consider the headers defined within the HTTP document set to be extensions.
If the facts of the case are that some client sent you an If-Unmodified-Since header, and your implementation ignored it, and as a consequence Big Expensive Mess happened, you are not going to be happy with the advice from your attorneys.