mrpotes

Yep, I thought the same thing - I've referred the article to the UK Competition and Markets Authority, and to the UK Consumers' Association.

You can also dissolve gold in lead, as my great-uncle discovered when he thought he'd hidden his money somewhere safe when a UK Nazi invasion seemed imminent during the second world war...

Is the answer not "Because you sold out"? What did he expect to happen when Google snapped them up?

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'.