Skip to content
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

HTTP headers: deprecating "(Want-)?Digest", adding "(Want-)?(Content-|Repr-)Digest" #26885

Open
wants to merge 39 commits into
base: main
Choose a base branch
from

Conversation

jfrech
Copy link

@jfrech jfrech commented May 21, 2023

Legacy description based off of draft 7.

@jfrech jfrech requested a review from a team as a code owner May 21, 2023 21:03
@jfrech jfrech requested review from teoli2003 and removed request for a team May 21, 2023 21:03
@github-actions github-actions bot added the Content:HTTP HTTP docs label May 21, 2023
@github-actions
Copy link
Contributor

github-actions bot commented May 21, 2023

@hamishwillee
Copy link
Collaborator

Thanks very much. This is great but we'll want to do more. From the current spec:

Introduced Repr-Digest and Want-Repr-Digest, and deprecated Digest and Want-Digest. Use of Structured Fields. 1993, 1919

So we want to deprecate Want-Digest and add Repr-Digest and Want-Repr-Digest. Do you want to take a shot at that?

Note that there are a couple of macros we use to indicate deprecation - I added one above for the header, but in lists of headers and whatever you can use {{Deprecated_Inline}}.

If `Repr-Digest is a representation header we'll want to add it here too: https://developer.mozilla.org/en-US/docs/Glossary/Representation_header

@teoli2003 The deprecated macro should really be able to include the information in @jfrech warning block. Can we modify the macro to allow specification of what the deprecation cause/replacement is?

@jfrech
Copy link
Author

jfrech commented May 29, 2023

@hamishwillee In e. g. Sec-CH-UA-Full-Version, deprecation replacement is indicated by a Note. I only used a Warning since e. g. Accept-CH-Lifetime notes a draft removal as a Warning.
So a more specific way to note prior feature existence and/or recommended newer alternatives may indeed be nice to have.

@jfrech
Copy link
Author

jfrech commented May 29, 2023

@hamishwillee May I double-check my interpretation of the spec with you?

I read it to claim the Repr- to be the Selected Representation, fully dependent on Content Negotiation which takes Content-Type into account. Does this mean Content-Digest is of no use whatsoever if the "actual message content" (cf. https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers-12#section-2) is not selectable as a representation (e. g. MDN's source files only being selectable as HTML)?

@jfrech jfrech changed the title HTTP header "Digest": set status to "deprecated", fixed legacy description HTTP headers: deprecating "(Want-)?Digest", adding "(Want-)?(Content-|Repr-)Digest" May 29, 2023
@jfrech jfrech requested a review from a team as a code owner May 29, 2023 20:43
@github-actions github-actions bot added the Content:Glossary Glossary entries label May 29, 2023
@jfrech
Copy link
Author

jfrech commented May 29, 2023

@hamishwillee Should we remove "Content-Location" from the glossary? After all, it does not describe the representation sent by the associated HTTP message.

@hamishwillee
Copy link
Collaborator

g. Sec-CH-UA-Full-Version, deprecation replacement is indicated by a Note. I only used a Warning since e. g. Accept-CH-Lifetime notes a draft removal as a Warning.

Yes, it would be great to be able to include deprecation replacement info in the macro itself, allowing just one note to be used to indicate deprecation. Let's see if we can get traction here: mdn/yari#8969.

I'm going to change to a note. This is purely my taste - there is no real rule as far as I know.

@github-actions github-actions bot removed merge conflicts 🚧 Content:CSS Cascading Style Sheets docs Content:WebExt WebExtensions docs Content:SVG SVG docs Content:Other Any docs not covered by another "Content:" label Content:wasm WebAssembly docs Content:HTML Hypertext Markup Language docs Content:JS JavaScript docs Content:Learn Learning area docs Content:Accessibility Accessibility docs Content:WebAPI Web API docs Content:Media Media docs labels Jun 16, 2023
@hamishwillee
Copy link
Collaborator

hamishwillee commented Jun 16, 2023

@jfrech Other than the linter nits I think I've taken this as far as I want to. @teoli2003 should be around soon, and hopefully will take this to the end. He's far more experience than me on this!

Copy link
Member

@teoli2003 teoli2003 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few extra points, but overall this looks good and close to be ready


Representation headers may be present in both HTTP request and response messages.
If sent as a response to a `HEAD` request, they describe the body content that _would_ be selected if the resource was actually requested.
Whilst representations are different forms of resources, representations can themselves also be transmitted in different forms: an HTTP message frames (cf. e. g. HTTP/1.1's {{HTTPHeader("Transfer-Encoding")}}) a particular stream of octets (cf. e. g. {{HTTPHeader("Content-Range")}}) derived from the _selected representation_.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Whilst representations are different forms of resources, representations can themselves also be transmitted in different forms: an HTTP message frames (cf. e. g. HTTP/1.1's {{HTTPHeader("Transfer-Encoding")}}) a particular stream of octets (cf. e. g. {{HTTPHeader("Content-Range")}}) derived from the _selected representation_.
While representations are different forms of resources, representations can themselves also be transmitted in various forms: an HTTP message frames (cf., e.g., HTTP/1.1's {{HTTPHeader("Transfer-Encoding")}}), a particular stream of octets (cf., e.g., {{HTTPHeader("Content-Range")}}) derived from the _selected representation_.


## See also

- [RFC 9110, section 3.2: Representations](https://httpwg.org/specs/rfc9110.html#representations)
- [List of all HTTP headers](/en-US/docs/Web/HTTP/Headers)
- {{Glossary("Payload header")}}
- {{glossary("Entity header")}}
- {{HTTPHeader("Digest")}}/ {{HTTPHeader("Want-Digest")}}
- {{HTTPHeader("Repr-Digest")}}, {{HTTPHeader("Want-Repr-Digest")}}
- pertaining to particular forms of the selected representation: {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Want-Content-Digest")}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- pertaining to particular forms of the selected representation: {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Want-Content-Digest")}}
- {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Want-Content-Digest")}}

As such, `Content-Digest` is dependent on among other things {{HTTPHeader("Content-Encoding")}} and {{HTTPHeader("Content-Range")}}, but not dependent on, for example, HTTP/1.1's {{HTTPHeader("Transfer-Encoding")}}.
`Content-Digest` may coincide with {{HTTPHeader("Repr-Digest")}} if a representation was sent in a single message.

"content" in this setting refers to a particular octet representation of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"content" in this setting refers to a particular octet representation of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource.
In this setting, _content_ refers to a particular octet representation of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource.


{{HTTPSidebar}}{{SeeCompatTable}}

The **`Repr-Digest`** response or request header provides a {{Glossary("digest"}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. It is invariant under e. g. {{HTTPHeader("Content-Encoding")}} or {{HTTPHeader("Content-Range")}}, which do affect the {{HTTPHeader("Content-Digest")}}. Note furthermore that [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representation with respectively different representation digests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The **`Repr-Digest`** response or request header provides a {{Glossary("digest"}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. It is invariant under e. g. {{HTTPHeader("Content-Encoding")}} or {{HTTPHeader("Content-Range")}}, which do affect the {{HTTPHeader("Content-Digest")}}. Note furthermore that [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representation with respectively different representation digests.
The **`Repr-Digest`** response or request header provides a {{Glossary("digest"}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. It is invariant under e.g., {{HTTPHeader("Content-Encoding")}} or {{HTTPHeader("Content-Range")}}, which do affect the {{HTTPHeader("Content-Digest")}}. Furthermore, [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representations with different representation digests.

Comment on lines +30 to +32
`Repr-Digest` describes an [RFC8941 dictionary](https://www.rfc-editor.org/rfc/rfc8941#section-3.2) with its keys being names of digest algorithms and its values being the digest in bytes (or an integer digest for legacy digest algorithms).

> **Note:** In contrast to earlier drafts of the specification, the standard-base64-encoded digest bytes are wrapped in colons (`:`, ASCII 0x3A) as part of the [dictionary syntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should have a glossary entry for RFC8941 dictionary: I don't like to send readers to the spec (that are difficult to understand) to grasp the syntax.

...
```

### Example: HTTP responses where {{HTTPHeader("Repr-Digest")}} and {{HTTPHeader("Content-Digest")}} diverge
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Example: HTTP responses where {{HTTPHeader("Repr-Digest")}} and {{HTTPHeader("Content-Digest")}} diverge
### HTTP responses where {{HTTPHeader("Repr-Digest")}} and {{HTTPHeader("Content-Digest")}} diverge

...
```

### Example: Successful HTTP request-response employing {{HTTHeader("Want-Repr-Digest")}}, {{HTTHeader("Repr-Digest")}}, {{HTTHeader("Content-Digest")}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Example: Successful HTTP request-response employing {{HTTHeader("Want-Repr-Digest")}}, {{HTTHeader("Repr-Digest")}}, {{HTTHeader("Content-Digest")}}
### Successful HTTP request-response employing {{HTTHeader("Want-Repr-Digest")}}, {{HTTHeader("Repr-Digest")}}, {{HTTHeader("Content-Digest")}}

...
```

### Example: Unsuccessful HTTP request-response employing {{HTTHeader("Repr-Digest")}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Example: Unsuccessful HTTP request-response employing {{HTTHeader("Repr-Digest")}}
### Unsuccessful HTTP request-response employing {{HTTHeader("Repr-Digest")}}


`Want-Content-Digest` describes an [RFC8941 dictionary](https://www.rfc-editor.org/rfc/rfc8941#section-3.2) with its keys being hashing algorithms and its values being the integers `0` (meaning "not acceptable") or `1` to `9` (conveying ascending, relative, weighted preference).

> **Note:** In contrast to earlier drafts of the specifications, the weighting is *not* declared via [q-values](/en-US/docs/Glossary/Quality_values).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> **Note:** In contrast to earlier drafts of the specifications, the weighting is *not* declared via [q-values](/en-US/docs/Glossary/Quality_values).
> **Note:** In contrast to earlier drafts of the specifications, the weighting is _not_ declared via [q-values](/en-US/docs/Glossary/Quality_values).


`Want-Repr-Digest` describes an [RFC8941 dictionary](https://www.rfc-editor.org/rfc/rfc8941#section-3.2) with its keys being hashing algorithms and its values being the integers `0` (meaning "not acceptable") or `1` to `9` (conveying ascending, relative, weighted preference).

> **Note:** In contrast to earlier drafts of the specifications, the weighting is *not* declared via [q-values](/en-US/docs/Glossary/Quality_values).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> **Note:** In contrast to earlier drafts of the specifications, the weighting is *not* declared via [q-values](/en-US/docs/Glossary/Quality_values).
> **Note:** In contrast to earlier drafts of the specifications, the weighting is _not_ declared via [q-values](/en-US/docs/Glossary/Quality_values).

@bsmth bsmth added the awaiting response Awaiting for author to address review/feedback label Dec 8, 2023
@bsmth
Copy link
Member

bsmth commented Jan 9, 2024

Hi @jfrech - thanks a lot for the submission. There are some review comments outstanding above, would you like to come back to this one? @teoli2003 has indicated that "this looks good and close to be ready", so it would be great to have your work land eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting response Awaiting for author to address review/feedback Content:Glossary Glossary entries Content:HTTP HTTP docs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants