Placement 最小 HTTP 缓存头¶

https://blueprints.launchpad.net/nova/+spec/placement-cache-headers

RFC 7232 第 2.2 节 指出，Web 服务应该为任何可以合理推断出最后修改时间的资源发送一个 last-modified 头。Placement 服务目前没有这样做。包含它将使其成为一个更好的 HTTP 公民，并提供响应中有用的元数据。如果添加了 last-modified 头，那么添加一个值为“no-cache”的 cache-control 头也是必要的，以确保客户端和代理不会倾向于缓存 Placement 服务提供的资源。

问题描述¶

由于没有发送适当的缓存头，Placement 存在两个小问题

它没有遵循 HTTP 服务的公认标准。
客户端和代理在向 Placement 发送请求时，可能会缓存服务响应。鉴于 Placement 提供的多数数据高度依赖时间，这是个问题。

用例¶

作为 HTTP API 的用户，我期望它遵循标准并向我提供一个 last-modified 头，该头反映了资源的最后修改时间。

提议的变更¶

在一个新的微版本中，对于 Placement 服务处理的任何 GET 请求，在响应中添加两个额外的头

last-modified 具有有意义的时间和数据值（见下文）。
cache-control 具有 no-cache 的值。有关更多详细信息，请参阅 RFC 7234 第 5.2.1.4 节。

last-modified 头的取值来自三个不同的选项

如果请求是直接与数据库行关联的单个实体，并且该行具有 updated_at 或 created_at 字段，则将使用其中一个字段的值，如果已设置则优先使用 updated_at（如果资源仅创建但尚未更新，则不会设置）。
如果请求是直接与数据库关联的实体集合，则该值将是集合中所有实体的 updated_at 或 created_at 的最大值。
如果请求是包含多个部分的实体或集合，则该头的取值将是当前时间。

备选方案¶

一个可行的替代方案是不做任何事情。如果我们不添加 last-modified 头，那么缓存的风险很小（因为没有存在条件头）。但那样我们就成了不好的 HTTP 公民。

另一种替代方案是在 Placement 服务中开始使用 ETags。这将能够实现相当复杂和完整的服务器端和客户端资源缓存，从而节省带宽和数据库查询。然而，这是一项相当重要的任务，并且不会消除对 last-modified 头需求的，因此最好采取较小的步骤来实现完整的头套件。

数据模型影响¶

数据库表已经具有所需的 updated_at 和 created_at 字段，但 nova/objects/resource_provider.py 中的 OVO 需要更新以暴露这些字段。这可以通过使用 NovaTimestampObject mixin 来完成。

REST API 影响¶

如前所述，每个 GET 请求都会获得两个额外的头 cache-control: no-cache 和 last-modified: <timestamp>。这些将仅在新创建的微版本中公开。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

如果我们认为调度器报告客户端是 Placement 的主要“最终用户”，那么这些头将对它没有影响，特别是由于客户端在其请求中使用显式的微版本。

性能影响¶

请求大型集合时会产生轻微的影响。该集合被遍历以找到 last-modified 值。通过将这项工作与创建 JSON 响应体的现有遍历结合起来，可以减轻大部分影响。

其他部署者影响¶

无。

开发人员影响¶

当开发人员向 Placement 服务添加新的 GET 请求处理程序时，他们需要添加这些头。

实现¶

负责人¶

主要负责人: cdent
其他贡献者: 无

工作项¶

为此功能创建一个新的微版本
更新 nova/objects/resource_provider.py 中的对象以暴露 updated_at 和 created_at 字段
对于每个 GET 请求的处理程序，添加这些头
更新 gabbi 测试以检查新的头，并确认它们在新微版本中存在，而在旧微版本中不存在
更新 placement api-ref

依赖项¶

无。

测试¶

如工作项中所述，重要的是确认头在新微版本中按预期显示。同样重要的是确认它们在旧微版本中_不_显示。

文档影响¶

无

参考资料¶

历史¶

修订版¶
发布名称	描述
Queens	引入

Placement 最小 HTTP 缓存头