Inconsistent behaviour of static file serving

If Tornado (3.1) is not running in debug mode, when a static file is accessed for the first time the included StaticFileHandler will generate an MD5 hash for it and store that hash in perpetuity. The handler will then read the content of the file and serve it up with the corresponding version and ETag. The next time the same client requests the file we get a 304 response and the client uses its own copy from its cache.

Now let's modify the file and change something interesting in the static file. If the original client now requests the file again, we still get the cached copy from the local browser since the ETag is linked to the cached hash in Tornado.

Consider now what happens if another distinct client that has not accessed the file before tries to fetch the same static file. Tornado will happily serve up the file, but it reads it off the disk again, and that client gets the new version of the file, but since Tornado already has a cached hash for that file it serves the new file with the old ETag. So now we have two different versions of the same file with the same ETag being shown on two different clients.

Some ideas:

• Cache the file along with the hash and always serve it consistently -- memory issues.
• Update the hash when the file is read by the second client -- inconsistent state, the original client shouldn't get a different response on the off chance that another client without a locally cached copy has fetched since the original client did.
• Change the ETag / revision hashing to avoid assigning the same hash two different versions of the file -- this would oblige some kind of stat call to see if the file has changed and would always serve the most recent version -- it would also need to check the hash is up to date when using static_url calls.

Start with StaticFileHandler and the static_url path described in the issue. Reproduce the sequence with two clients: access a file, modify it, then request it from the original and a new client. Done means changed files do not produce different content under the same ETag, without relying on an unspecified caching strategy.