- From: Roberto Polli <robipolli@gmail.com>
- Date: Mon, 14 Jun 2021 14:47:15 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>
Dear folks, since in the past meetings and on the list there was a demand for a checksum mechanism based on the actual data transferred on the wire (eg. the content) instead of the representation data, with Lucas we decided to create a PR introducing the `Content-Digest` field. @Lucas Pardue please feel free to integrate/clarify on everything. Implementers that don't care about partial representation and just want to implement a checksum mechanism eg. in a reverse proxy, might prefer Content-Digest. Implementers writing applications that need to verify the actual application data (e.g. the checksum of a pdf file after resuming a download) might prefer using Digest instead. Both fields are independent from each other, so it is legit to use both, though we don't know whether it's worth mentioning that in the spec. This is a preliminary PR that we want to present at tomorrow's meeting: clearly it needs further work. - https://github.com/httpwg/http-extensions/pull/1543/files This new field, with the same syntax and algorithms of `Digest` is thus computed on the actual content bits sent in the request or response. Here you can see a brief list of possibilities: 1. in the general case, eg. a simple GET, Digest and Content-Digest will convey the same values. 2. When partial representations are conveyed (eg. range-requests), Digest will contain the checksum of the whole representation-data, while Content-Digest will be computed on the actual exchanged bits. 3. For HEAD responses, Digest will convey the checksum of the selected representation data, while Content-Digest, since there's no content, will convey the checksum of an empty string. FYI interim slides are here: - https://docs.google.com/presentation/d/1W6Bc4G6OgkcMjuppOgjhynVF5wXsNG2RA2P_ZyMHYp4/edit#slide=id.gdc080ffd07_0_6 In the meantime, thanks to everyone for helping us in this long work, R.
Received on Monday, 14 June 2021 12:48:05 UTC