与HTTP规范的大多数方面一样，最终的责任在于提供资源的人。
当然，通常使用我们的工具（服务器，负载平衡器，应用程序框架等）来帮助我们履行这些职责。但是，没有任何规范定义期望与应用程序相对应的“
Web服务器”提供的内容，这只是您所使用的工具中可用功能的实际问题。
现在，
ETags特别看一下，一种常见情况是可以将框架或Web服务器配置为自动对响应（主体或其他内容）进行哈希处理并将结果放入中
ETag。然后，根据条件请求，它将生成响应并将其哈希以查看其是否已更改，如果没有，则自动发送条件响应。
举两个我熟悉的例子，nginx可以在Web服务器级别使用静态文件来执行此操作，而Django可以在应用程序级别通过动态响应来执行此操作。
这种方法很常见，易于配置，并且效果很好。但是，在某些情况下，它可能不是最适合您的用例的。例如：
- 要计算散列以与传入的散列进行比较，
ETag
您首先必须有一个响应。因此，尽管条件响应可以为您节省 发送 响应的开销，但不能节省 生成 响应的成本。因此，如果生成响应的成本很高，并且您有其他来源ETags
（例如，存储在数据库中的版本号），则可以使用它来获得更好的性能。 - 如果你打算使用
ETags
，以防止意外覆盖具有状态改变的方法，你可能需要添加自己的应用程序代码，以使您的比较和组逻辑原子。
因此，在某些情况下，您可能想
ETags在应用程序级别创建您的应用程序。再次以Django为例，它提供了一种简单的方法来提供自己的计算功能
ETags。
总之，提供
ETags您所控制的资源最终是您的责任，但是您很可能能够利用软件堆栈中的工具为您完成这些工作。
