Chromium的当前net/disk_cache/simple file模块没有实现缓存的原子更新

问题：当服务器端初始响应浏览器的HTTP GET请求并设置Date头部字段，浏览器缓存了cache的第一个版本；其后下一次请求revalidate时，浏览器设置If-Modified-Since，并期望得到一个304。不幸的是，浏览器却返回了200，并重新发回完整的response body响应。这种情况下，Chromium的net/disk_cache/simple file模块将尝试更新cache entry。问题是，如果这个下载过程中，如果网络突然中断，浏览器对应此URL请求的缓存数据将被破坏。原来的cache也没有了。

原因是：Chromium的当前net/disk_cache/simple file模块没有实现缓存的原子更新。有一个simple index索引文件，倒是有点像是数据库文件，它的更新倒是原子的：——先写一个临时文件，待临时文件写完成后，删除目标文件，并重命名临时文件为目标文件。

假如simple file的设计是每个cache entry文件有0，1，2三个stream，可以单独更新（？），那么仅仅在API实现的下一层级别做简单的修改可能不能实现cache的atomic update。或者至少要更麻烦一点。

可以考虑在上层解决这个问题：假设对每个HTTP Cache请求，虽然不是每个URL对应相同的response body内容，但是我们加上Last-Modified或者ETag（有后者的情况下，优先选择后者），那我们确保对于<string URL, long Last-Modified>二元组，或者<string URL, string ETag>都有一个唯一的快照版本。

对于只使用ETag区分服务器版本的情况，浏览器客户端本地需要维护一个long Local-Updated时间戳，这样才能够定位到最新的cache是哪一个。

我得承认，Chromium内核的当前net IO模块代码使用了C++加回调来进行异步IO操作，内部维护了状态机，这一切都很巧妙（区别于传统的同步阻塞IO编程），问题是：所有的文件IO操作应该满足ACID（类似于数据库系统实现的约束），可是它没有；同时异步IO下状态机模型的每个状态命名都很令人费解。本来代码上应该做更多的语义-名字映射的。