我在声明中缺少任何观点吗？
我想知道目标节点是否有办法在不使用“自定义代码/API”的情况下检查文件逻辑完整性。
https仅在TLS层上的HTTP，因此所有这些都适用于HTTPS：
甚至指定MD5校验和标头字段。您可以配置Web服务器以使用该字段，客户端可能会使用它来验证整体文件完整性。 RFC2616指定的content-md5似乎已被弃用。您现在可以使用
含有含义的摘要，这更灵活。
，您也提到要检查客户端发送到服务器的文件。这个问题可能要困难得多 - 虽然您通常可以完全控制Web服务器，但您不能在上传之前强迫任意客户端（例如浏览器）哈希文件。另一方面，如果您实际上可以控制客户端的HTTP实现，那么您也可能会使用比普通HTTP更面向文件传输的东西 - 想想WebDav，Atompub等，它是HTTP的协议，是HTTP的协议，甚至还有更多面向文件交换的协议（例如Rsync）（如果您实际上同步的内容，我会衷心建议您将网络用法降低到两个侧面版本仅部分不同的情况下）。如果出于某种原因，您的用户可以在一个定义明确的圆圈中共享他们的大部分数据（例如，您正在构建摄影师共享专辑的东西），那么您甚至可能只使用Bittorrent，而Bittorrent则可以-Chunk Hashing，广泛的负载平衡选项，并允许“普通的旧HTTP种子”。
这里有几个问题：马库斯说，他的答案是他的答案TCP可以保护您的字节免受偶然的损坏，但是如果下载中断，这无济于事。 https还确保这些字节不会被服务器和客户端（您）
如果您想验证文件的完整性（其传输或未中断）
您应该使用校验和设计来防止意外文件损坏（例如CRC32，可能会有更好的文件，您应该检查）如果您使用https，那么您也可以免受故意攻击，因为您知道校验和可以，并且您不会被篡改的文件部分。
如果您使用校验和不使用HTTPS（但您确实应该），那么您应该安全地防止意外数据损坏，而不是针对恶意攻击。它可能会得到缓解，但它不在这个问题的范围之内。