是否有一个标准的HTTP非不透明的，基于散列的ETag报头？

Question

长话短说，我想明确指出一个给定的哈希算法(SHA256)，用于计算资源的HTTP头( ETag header )。据我所知，ETag标头值在设计上是不透明的，但在实践中，通常使用散列函数来计算它。

我理解保持ETag值不透明的想法，我猜这是为了通过缓存代理来防止意外的优化，这些代理将尝试解释它的值，并执行其他操作，而不是将当前的ETag与缓存的ETag进行比较。但是，我想知道是否有人编写了一个RFC，它定义了额外的HTTP头的用法，它将显式地指示用于计算相应的HTTP值的散列算法，从而使其成为非不透明的，同时保持与只依赖于不透明的ETag值的缓存代理的兼容性。

在我的例子中，我没有使用缓存代理:我有一个本机应用程序，它应该从自己的HTTP微服务中获取多个资源，这意味着我可以控制HTTP客户端和服务器实现。其中一些资源应该存储在磁盘上，作为优化，我想简单地加载当前文件，计算它的SHA256和，并在再次从我的微服务中获取相同的资源时，将其用作最后一个缓存资源的ETag。

换句话说:我在不经常更改的特定资源上发出GET请求，但我仍然需要定期检查。我希望计算文件的SHA256和并将其用作ETag，而不是每次都通过网络传输资源，从而避免将不透明的ETag与文件一起保存。因为我控制为资源提供服务的微服务，所以我可以很容易地使用SHA256 sums作为ETag，并添加一个自定义标头来指示SHA256用于计算ETAg。对于不检查自定义头的客户端，此ETag可以保持不透明，但可以将其视为SHA256总和的客户端。

这样的东西有没有已知的实现？我可以使用不被广泛认可的晦涩的RFC，或者一些REST API文档，但在制作自己的设计之前，我更愿意寻找可以实现的现有设计。如果我错过了广泛认可的标准，它将超出我的期望:)

Answer 1

任何标准或RFC都没有给出REST服务的语义。只有你可以指定你的REST服务的语义。此规范在HTTP (等)的基本约束之上添加了约束或解释。如果你想通过指定你的服务返回的ETag是表示的SHA256校验和，你可以。不需要更多的东西。您不需要特殊的额外头部，也不需要遵守一些外部产生的标准。