Fix: #1542. Add Content-Digest. #1543
Conversation
|
I think this is a good start. I took a stab at updating the concept overview to better draw out the differences between Digest and Content-Digest - see https://github.com/httpwg/http-extensions/compare/ioggstream-1542...lucas/content-digest-plusplus?expand=1 Think we should wait for WG feedback before landing this PR into main branch though. |
Co-authored-by: lucas <lucaspardue.24.7@gmail.com>
|
@LPardue integrated your suggestion in the PR, thanks! |
|
Thanks. (And thanks for putting together the bulk of this pr!) I think the changes to overview set an example of the kinds of changes we probably need to make throughout the document. But for now what's here is indicative enough of the Content-Digest change to let people assess it does solve their issues. |
|
After we get consensus on the doc's content, I'm even ok to do an editorial rewrite from scratch :DDD |
| @@ -318,6 +327,79 @@ Want-Digest: sha-256 | |||
| Want-Digest: sha-512;q=0.3, sha-256;q=1, unixsum;q=0 | |||
| ~~~ | |||
|
|
|||
|
|
|||
| # The Content-Digest Field {#content-digest} | |||
There was a problem hiding this comment.
So, strictly speaking, this field name is appropriate according to the current terminology in Semantics.
What triggered my unease was that the Content- prefix is used on several headers that don't refer to the actual content of the message (using the current Semantics definition) -- they refer to the representation. See httpwg/http-core#878.
I think it's safe to ship this as Content-Digest as long as it's being super-precise about what it's referring to.
I could also see flipping Content-Digest's semantics with Digest, to align with most (but not all) other uses of the Content- prefix. I'm not convinced that doing so is necessary, or even preferable; just mentioning it as something to consider.
There was a problem hiding this comment.
Good insight Mark, we'll provide an example of Content-Digest vs Digest in the same message.
About flipping, I think that Content-Digest, being similar to Content-md5 seems to me a more intuitive name.
There was a problem hiding this comment.
Flipping names seems bad to me. Prefer the way we suggested
There was a problem hiding this comment.
Wouldn't flipping the names be problematic with respect to compatibility with existing implementations of RFC3230's Digest?
|
|
||
| # The Content-Digest Field {#content-digest} | ||
|
|
||
| The `Content-Digest` field contains a comma-separated list of one or more content digest |
There was a problem hiding this comment.
Since we're defining a new header here, can we just use structured fields for it entirely? So it'd be a dictionary with the field names as algorithms and the values as binaries.
There was a problem hiding this comment.
Excellent question. I like the idea but think that it would make it awkward because the algorithms define their encoding. So you'd have to carve out some exceptions and differences, which might catch implementers out.
There was a problem hiding this comment.
I wanted to switch to SF, but after a long discussion it was suggested to retain the current grammar,
even because SF do not support uppercase dictionary keys: this is a show stopper wrt being backward compatible.
Moreover I don't agree wrt using different parsers for C-D and D: it is valuable that the same parser can process both fields.
|
@LPardue should we create a separate example section for Content-Digest or just add some examples in parallel with Digest? |
* Add examples for content-digest. * contentMD5 -> want-content-digest Co-authored-by: Lucas Pardue <lucaspardue.24.7@gmail.com>
| It can be used in both requests and responses. | ||
|
|
||
| ~~~ | ||
| Want-Content-Digest = 1#want-digest-value |
There was a problem hiding this comment.
Given how similar Want-Digest and Want-Content-Digest are, and that they share the want-digest-value we can probably editorialize this a bit. But in order not to block this PR, we can do that work in a follow up.
Co-authored-by: Lucas Pardue <lucaspardue.24.7@gmail.com>
This PR