协商缓存

所谓基于摘要和基于时间戳的协商缓存机制已经背的滚瓜烂熟了，然而今天在实践的时候却踩了坑。

在 POST/PUT（也许还有其他的）请求中，Chrome（其他的应该也是如此） 会忽略响应中的 ETag header，忽略的行为指对下次相同 url 的请求不会如预期地带上 If-None-Match。

在 HTTP/1.1 RFC 中关于 POST 的部分，并未提到这一行为。

在 HTTP/1.1 Semantics and Content 中，对 PUT 有一段相关解释：

An origin server MUST NOT send a validator header field(Section 7.2), such as an ETag or Last-Modified field, in a successful response to PUT unless the request’s representation data was saved without any transformation applied to the body (i.e., the resource’s new representation data is identical to the representation data received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 5.2).

对 POST/PUT 请求响应的 ETag 应该由客户端自行抽象和处理。

而当下在写的博客 backend 对所有 api 统一抽象为 POST，于是在前端实现了一个 运行时缓存，并在 api call 抽象层中实现了运行时的基于摘要的协商缓存。

后端则是实现了对 POST 有效的协商缓存中间件。