What is the use of If-Unmodified-Since HTTP Header?

Question

Do you know of any practical use of If-Unmodified-Since in the wild? From the description, it appears that this header was meant to help with avoiding dirty writes. i.e. update this resource only if it hasn't been modified since the last-modified-time available with client. Unlike If-Modified-Since, it doesn't seem to help with caching. Am I missing something?

Answer 1

You can use it e.g. for a range request.
example: your client requests the resource http://examp.le/foo?id=3 and the Contents-length is 4096 but your client only requests the first 1024 bytes. It can then (at a later time) request the remaining 3072 bytes but that doesn't make sense if the resource has changed meanwhile.

edit: Also you might not want to change/update data if the resource has changed meanwhile. E.g. you request a customer record and edit something. If someone else has changed the record in the meantime this might lead to inconsistencies. Therefore send your updates with an if-unmodified-since(-I-retrieved-the-data) header and the webserver will/should reject your updates if the record has already been changed - your client can then request the "conflicting" data.

edit2: since you've asked for "any practical use of If-Unmodified-Since in the wild": see http://msdn.microsoft.com/en-us/library/dd179371.aspx#Subheading1.
Let's assume you've first requested the Blob properties. Now you know e.g. the Content-type and Content-length (maybe you need this for some kind of allocation). Someone/something might change the blob before you send the second, Get Blob request. If you send the value of Last-Modified as value of the If-Unmodified-Since header the server will respond with the appropriate error code if the blob has changed.

---

Those are examples of an optimistic lock/stamped lock as a means of concurrency control, where the value of the Last-Modified header serves as the guard token. See e.g. https://en.wikipedia.org/wiki/Optimistic_concurrency_control

Answer 2

It's useful for multiple requests, conducted over a period of time, but relating to a single unchanged resource.

Examples:

• Range requests. The response to the first range request (or perhaps a preliminary HEAD) includes the Last-Modified header. Subsequent requests are meant for the same version of that resource only. If the resource changed between the time we started the sequence of range requests and some time in the middle of the sequence, we want to start over.

• Optimistic concurrency control. We first GET a resource, make some changes client-side, and wish to PUT the updated resource. But we only want to PUT the updated resource so long as nobody else updated it in the meantime. We don't want to overwrite anybody's changes. If it turns out somebody has changed the resource in the meantime, we want to GET it again, attempt to re-apply the changes in the client (sort of like git rebase), and try to PUT the changed resource again.