I don't agree with the use of If-Modified-Since – the author seems to have elected to completely ignore the rest of the section of the RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...), specifically: "If the variant has been modified since the If-Modified-Since date, the response is exactly the same as for a normal GET."
What the author seems to be actually describing is exactly what the If-Range header has been designed for:
If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body.
The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.
What the author seems to be actually describing is exactly what the If-Range header has been designed for:
If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body.
The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.