是否有HTTP非不透明、基于哈希的ETag头的标准？

长话短说，我想明确指出一个给定的哈希算法（SHA256），该算法用于计算资源的HTTP ETag头。按照我的理解，ETag头值在设计上是不透明的，但在实践中，通常使用散列函数来计算它

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

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

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

---

有这样的已知实现吗？我可以使用一个不被广泛认可的模糊RFC，或者一些RESTAPI文档，但我更愿意在创建自己的设计之前寻找可以实现的现有设计。如果我错过了广泛认可的标准，那将超出我的期望：）

任何标准或RFC都没有给出REST服务的语义。只有您可以指定REST服务的语义。该规范在HTTP（等）的基本约束之上添加了约束或解释。如果要指定服务返回的

ETag

是表示的SHA256校验和，可以。不需要更多了。您不需要特殊的额外标题，也不需要符合某些外部生产的标准。

Content-MD5

曾经是一个东西，我不知道有任何这样的实现，但您可以始终使用自己的自定义标题来实现此目的。（或者简单地假设SHA256，因为您同时控制客户端和服务器？）这不是一个标准，但Apache httpd和nginx都使用文件长度和文件修改时间来计算静态服务文件的ETag。