使用HTTP头的消息完整性检查，因为Content-MD5已被弃用？

Question

使用HTTP头的消息完整性检查，因为Content-MD5已被弃用？

12

制作一个基于大文件上传/下载的REST Web服务器，我希望能够检查文件完整性。我认为使用Content-MD5 HTTP标头 [0] 是正确的方法，因为AWS的经验证明它很有用 [1]。然而，令我沮丧的是，我最近了解到它已被（要）弃用 [2]。讨论中没有给出任何替代方案提示，所以我想问：

- 我是否仍应决定使用Content-MD5 HTTP标头？ - 我应该使用具有相同含义（MD5校验和的base64编码）的ETag吗？ - 我应该使用“md5sum=XXX”参数吗？ - 是否有更好的解决方案？

感谢您的见解。

最好的问候， B.

[0] https://webmasters.stackexchange.com/questions/2924/ [1] http://developer.amazonwebservices.com/connect/thread.jspa?threadID=22709 [2] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/178

- user687718

3个回答

1

添加自定义头，称为 "X-YourService-Integrity"。这样明确表示它是专为您的服务而设计的系统，并允许您在未来使用除MD5之外的完整性检查机制（例如SHA1）。它还避免了您必须“过载”现有类似但不完全符合您要求的机制的情况。

- Brian Kelly

谢谢您的回答。然而，在传输过程中，自定义HTTP头可能会被删除，我没有看到与ETag相比的优势，ETag可以用于任何完整性检查，因为验证器实现是由标准http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3开放的。 - user687718

在传输过程中为什么会丢失一个头部？ - Brian Kelly

感谢您对此事的跟进。我目前正在搜索文本（我确信我曾经阅读过实现应该仅保留非标准标头，但我找不到权威参考资料）。值得一提的是，“X-”命名约定是不鼓励使用的http://tools.ietf.org/html/draft-saintandre-xdash-03。 - user687718

我不确定你还有多少其他可取的选择。ETag 应该是由服务器分配的，而这个值是由客户端分配的。URI 也不是它的位置，因为完整性哈希与表示相关，而不是服务器资源。虽然 X- 标头不被鼓励使用，但在你发布的链接中有方法可以添加自定义标头。这是元数据，元数据应该放在标头中。如何构建标头取决于你和你的应用程序的需求。 - Brian Kelly

1

https://www.ietf.org/rfc/rfc3230.txt

4.3.2 摘要

摘要消息头字段提供了消息所描述的实例的消息摘要。

  Digest = "Digest" ":" #(instance-digest)

消息描述的实例可能完全包含在消息正文中，部分包含在消息正文中，或者根本不包含在消息正文中。实例由请求URI和消息中包含的任何缓存验证器指定。

摘要头字段可以包含多个实例摘要值。例如，对于预期驻留在由具有不同浏览器的用户共享的缓存中的响应，这可能非常有用。

接收方可以忽略摘要头字段中的任何或所有实例摘要。

发送方可以使用摘要算法发送实例摘要，而不知道接收方是否支持摘要算法，甚至不知道接收方将忽略它。

示例：

  Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
  Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637

- Fabio Maulo

有没有一些支持静态内容的内置Want-Digest选项的Web服务器？还是每次都需要自己实现这个头部行为？我正在寻找一个现成的工具。 - Karolis Milieška

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Roberto Polli · Accepted Answer

不要使用Content-MD5：它已被弃用，因为会导致不一致性。

请使用sha-256或sha-512进行摘要。我们正在将RFC3230更新到最新的HTTP规范（RFC7231），并添加了许多有用的示例https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers-02。

Digest: sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo=

There Want-Digest allows requesting a specific Digest header.

Eg. The client requests a digest, supporting sha-256 and sha-512. The server replies with sha-256

Request:

GET /items/123 HTTP/1.1
Want-Digest: sha-256, sha-512

回复：

HTTP/1.1 200 OK
Content-Type: application/json
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

{"hello": "world"}

2023 注意：根据（目前）最新的草案（-13），“摘要”字段名已被废弃，在7.1. HTTP字段名注册中有一个很好的概述：

IANA被要求根据下表更新“超文本传输协议（HTTP）字段名注册表”注册表（[HTTP]）：

Field Name 状态参考 Content-Digest 永久本文档的第2节 Repr-Digest 永久本文档的第3节 Want-Content-Digest 永久本文档的第4节 Want-Repr-Digest 永久本文档的第4节 Digest 废弃 [RFC3230]，本文档的第1.3节 Want-Digest 废弃 [RFC3230]，本文档的第1.3节