Hash HTTP规范：不进行数据传输，因为服务器知道数据的散列

HTTP/WebDav规范是否允许此客户机-服务器对话框

客户机：我想把数据放到/user1/foo.mkv，它有这个哈希和：hash

服务器：好的，PUT成功了，您不需要发送数据，因为我已经知道这个哈希和的数据

注意：此PUT为初始上传。这不是一个更新

如果这是可能的，可以实现更快的文件同步

用例：WebDAV服务器为每个用户托管一个目录。几个用户上传了最喜欢的视频foo.mkv。在此示例中，收藏夹视频已存储在此位置：/user2/myfoo.mkv。第二次和随后的上传不需要发送任何数据，因为服务器已经知道了内容。这将减少大量的网络负载

先决条件：

• 客户端和服务器需要事先就哈希算法达成一致
• 服务器需要存储已知文件的哈希值

在自定义客户机和服务器中实现这一点非常容易。但那不是我想要的

我的问题是：是否有RFC或其他标准允许这样的对话

如果还没有标准，那么如何实现这个梦想呢

安全考虑

通过上面的对话框，它将能够访问knowhash的内容。示例：一个邪恶的客户端知道有一个哈希和为

1234567…

的文件。他可以完成上述两个步骤，然后客户端可以使用GET下载数据

围绕此扩展对话框的一种方法：

客户：我想把有这个散列和的数据放入：散列

服务器：好的，PUT会成功，但是为了确保您有数据，请将N到M的字节发送给我。我需要这个来确保您有哈希和和数据

客户端：N字节到M字节的数据是

abcde…

服务器：好的，你的字节和我的匹配。我相信你。上传成功，您不再需要发送数据

如何做到这一点？

由于似乎还没有规范，这部分问题仍然存在：

---

如何实现这个梦想

根据您的描述，似乎应该使用s

它专门设计用于将标记（通常是MD5哈希，但可以是任何内容）与资源的内容（和/或位置）相关联，以便以后可以判断资源是否已更改

PUT请求由ETag支持，并带有的

If Match

头

但是，您的用例稍有不同，因为您试图阻止对具有相同内容的资源进行放置，而

If Match

头仅用于允许对具有相同内容的资源进行放置

在您的情况下，可以改为使用标题：

“If None Match:*”的意思是该方法不能 如果源服务器（或 缓存（可能使用变化机制，见第14.44节）存在， 如果表示不存在，则应执行。这 该功能旨在用于防止PUT之间的争用 行动

---

尽管它的使用方式可能取决于实现：

请注意，PUT响应中ETag的含义并不清楚 在本文件或RFC 2616中定义（即ETag 表示资源是八位字节，八位字节相当于 PUT请求，或者服务器是否可以进行微小更改 存储时文档的格式或内容）。这是一个 HTTP问题，而不仅仅是WebDAV问题

---

如果您正在实现自己的客户机，我会这样做：

客户端通过

ETag

• 如果客户机看到它与它已有的匹配，则不要发送任何其他内容
• 如果不匹配，则发送PUT请求，如果没有匹配的头，则发送带有

---

更新 从您更新的问题来看，现在似乎很清楚，当收到PUT请求时，您希望在接受请求之前检查服务器上的所有资源是否缺少相同的内容。这意味着还要检查位于与PUT请求的目标位置不同的位置的资源

抱歉，目前还没有专门处理这种情况的规范。然而，ETag机制（和HTTP协议）被设计成具有足够的通用性和灵活性来处理许多情况，这就是其中之一

当然，这只是意味着您不能利用标准HTTP服务器逻辑——您需要自定义客户端和服务器端的代码

假设 在我进入可能的实现之前，需要做一些假设

如前所述，您需要同时控制服务器和客户端

根据内容生成ETag需要商定一个算法。这可以是MD5、SHA1、SHA2-256、SHA3，它们的组合的串联，等等。我将只提到作为ETag的算法输出，但如何做到这一点取决于您

可能的实现 如果这个简单的案例不适合你，这些都是从最简单的到越来越复杂的

可能的实施1 这假定您的服务器实现允许您在接收整个请求之前读取请求头并作出响应

客户端计算要上载的文件/资源的ETag

客户端向服务器发送PUT请求（位置无关紧要），如果没有包含ETag的匹配头

，则使用头
，并继续正常发送正文

服务器检查资源是否具有