-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flipping names seems bad to me. Prefer the way we suggested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't flipping the names be problematic with respect to compatibility with existing implementations of RFC3230's Digest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted at the interim, this looks like a worthwhile direction. Minor editorial nits while reading through, but no disagreements with the proposal.
|
||
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filed #1632
Co-authored-by: Lucas Pardue <lucaspardue.24.7@gmail.com>
This PR