If-Unmodified-Since: a date based conditional write

This is the date equivalent of If-Match, for servers and clients that track modification times rather than versions. The client says it last saw the resource at this timestamp and asks the server to proceed only if nothing has been written since. A newer modification time means somebody else got there first, and the answer is 412 with no change applied.

It is weaker than If-Match for the same reason If-Modified-Since is weaker than If-None-Match: one second of resolution. Two writes landing inside the same second look identical to the check, so a busy record can pass the condition while genuinely having changed. For anything where a lost update matters, an entity tag is the correct tool.

Where both headers appear, If-Match wins and the date is ignored. That mirrors the read side rule and exists for the same reason: when a client offers both a precise validator and an imprecise one, the server must decide on the precise one rather than picking whichever is convenient.

There is a second use on reads. A client resuming a partial download can send this header alongside a Range request so that, if the file changed while it was away, it receives a fresh 200 or a 412 instead of stitching new bytes onto an old prefix and producing a corrupted file.