大概很多人会饿死，不满现状又没能力

dev 过不了验证很正常，beta 都偶尔会有过不去验证的情况

@curiosity 有东西刮得动那镜头的镜片？

PUT 的 URL 必须指向**唯一**的资源， POST 的 URL 可以指向**资源的集合**，所以 PUT 无论调用几次一定是把这个**唯一**的资源更新成请求提供的内容，所以幂等

谁告诉我指纹在后面怎么完成这个动作：手机在桌子上，收到一条微信，看了看不是太重要的，解锁回个[facepalm]，锁屏

使用符合语义的提前返回

百度有参加 w3 ，我就是成员， tc39 的标准讨论偶尔也会去凑个热闹

只有一个 webview 的 app 会被苹果拒掉的

觉得不怎么懂就说了解，觉得自己很牛就写熟悉，打死不写精通

@shrimp929 手动贼方便，我还嫌电动的麻烦呢

@silenceeeee 你这么说就对了，事实上就是你对 HTTP 协议存在误解而自己下了个预定义，事实上浏览器并没有做错

浏览器的缓存有 2 种
一种叫验证性缓存，用 ETag 、 Last-Modified 、 If-None-Match 、 If-Modified-Since 来控制，其特点是会发一个请求给服务器来确认缓存是否有效，如果有效就返回 304 ，省去传输内容的时间
另一种叫非验证性缓存，或者有些人称为强缓存，用 Cache-Control 、 Expires 、 Pragma 来控制，其特点是一但有效就在有效期内不会发任何请求到服务器

从描述也能很容易看出来，非验证性缓存的优先级是高于验证性缓存的，因为有它在就根本不会发请求，自然也没有什么 If-None-Match 之类的东西出现的机会了
你看到的 200 from memory cache 就是非验证性缓存

那么为什么在 Chrome 下会有非验证性缓存呢？就是因为你没有设置 Cache-Control 这个头，没有这个头的话，其默认值是 Private ，在标准中也明确说了：

Unless specifically constrained by a cache-control
directive, a caching system MAY always store a successful response

翻译一下：如果没有 Cache-Control 进行限制，缓存系统**可以**对一个成功的响应进行存储

很显然， Chrome 是遵守标准的，它在没有检查到 Cache-Control 的时候对响应做了非验证性缓存，所以你看到了 200 from memory cache
同时 Safari 也是遵守标准的，因为标准只说了**可以**进行存储，而非**应当**或者**必须**，所以 Safari 不进行缓存也是合理的

我们可以理解为，没有 Cache-Control 的情况下，缓存不缓存就看浏览器高兴，你也没什么好说的。那么你如今的需求是“明确不要非验证性缓存”，则从标准的角度来说，你**必须**指定相应的 Cache-Control 头

所以综合下来，错的在你

@cszhiyue 只要服务器不像上次那样出事，我觉得也没啥 BUG 了……

@cszhiyue 但其实 wunderlist 也不需要啥新功能了，不更新就不更新呗，继续用着有啥不好的

另外 200 from memory cache 根本不是什么 Chrome 自己实现的策略，只要在本地 Cache 中 Chrome 的 devtool 就会显示这个信息，以区别是从远程获取的 200 响应

我觉得楼主还是认真把 HTTP 协议和 Browser Cache 搞清楚再说，这样胡乱毫无根据的猜测并不是一个工程师应该有的样子

你不设 Cache-Control 的话就会被缓存住这很正常啊，因为 Cache-Control 是 Private 啊

Unless specifically constrained by a cache-control
directive, a caching system MAY always store a successful response

怎么设这个头就看这吧：
http://stackoverflow.com/questions/49547/how-to-control-web-page-caching-across-all-browsers

你思考下，我厂的 thinkpad 笔记本分辨率是 1366x768 ，其中横向 1366 ，假设字体是 14px ，那么可以显示 97 个字符，但是你要考虑编辑器并不一定是全屏的，你还要开侧边栏和 minimap ，综合下来为了能顺利阅读设置为 80 个字符有什么不对吗