Django 条件 View 处理装饰器添加陈旧的 Etag

Question

我一直在尝试使用 Django 的条件 View 处理功能。基本上我想拒绝对一个实体的更新操作，如果它已经被另一个用户修改，并且这似乎与@ condition 一起工作得很好。 Django 提供的装饰器。

然而，在测试它时我注意到了一个问题，后来我检查了 Django 源代码，我发现我认为可能是一个错误，但只是想在向 Django 提交错误报告和修复之前先在这里确认.

装饰器在新请求到来时被调用，它首先根据传入装饰器的函数计算 ETag 和 Last Modified 时间戳，然后将控制权交给 get_conditional_response()功能。此处将执行 ETag 和 Last Modified 验证，如果它们与请求中提供的内容不匹配，请求将被拒绝。到目前为止一切顺利。

如果检查通过，则允许请求并调用 View 来处理请求并生成响应。在处理请求时，如果它是不安全的方法，例如PUT 或 PATCH，它会更新实体，这很可能会更改 ETag 和 Last Modified 值。

但是，我注意到对 PUT 或 PATCH 的成功响应会随着更新 之前计算的 ETag 或 Last Modified 时间戳发回实际上执行了，现在这些值是无效的或陈旧的。这对我来说似乎是错误的。在同一实体上执行新的 GET 然后在响应中为用户提供更新的 ETag 和 Last Modified 值。

你不觉得吗，condition() 装饰器应该检查请求方法是否不安全，然后它应该在 View 处理后重新计算 ETag 和 Last Modified，然后添加响应的新值？

Answer 1

我同意这里有一个错误，尽管我认为它与您描述的有点不同。

条件请求在 RFC 7232 中定义，但不幸的是，该文档并没有明确说明何时应在响应中使用条件 header 。它does say :

2.4. When to Use Entity-Tags and Last-Modified Dates

In 200 (OK) responses to GET or HEAD, an origin server...

这可能会导致人们假设标题的使用未在其他响应中定义。

然而，RFC 7231明确允许在对 PUT 的响应中使用 ETag，以匹配新的表示(正如您的直觉)。但是，请注意 this caveat :

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...

也就是说，客户端将使用 ETag 的存在与否来确定它的表示(它只是作为正文发送到 PUT)是否是实际存储的。 (有关这一点的更多详细信息，请参阅 this question。)

但是，Django 的条件请求 API 不允许进行这种区分。具体来说，用户无法指示 View 是否在没有“应用到 body 的转换”的情况下保存表示。因此 condition() 装饰器无法知道是否需要添加 ETag。

所以唯一要做的就是保守一点，在这种情况下根本不返回条件 header 。请随意创建一张票(否则我可以做)。