chore(http): Updates to headers pages

files/en-us/web/http/headers/forwarded/index.md

@@ -18,6 +18,10 @@ Therefore, the user's privacy must be kept in mind when deploying this header.
 
 The alternative and de-facto standard versions of this header are the {{HTTPHeader("X-Forwarded-For")}}, {{HTTPHeader("X-Forwarded-Host")}} and {{HTTPHeader("X-Forwarded-Proto")}} headers.
 
+> [!NOTE]
+> If upstream services rely on `X-Forwarded-*` headers, replacing them outright with `Forwarded` could lead to compatibility issues.
+> Verify that frameworks, middleware, and any third-party tools support the standardized version before deploying this header as a replacement.
+
 <table class="properties">
   <tbody>
     <tr>

files/en-us/web/http/headers/want-content-digest/index.md

@@ -2,13 +2,17 @@
 title: Want-Content-Digest
 slug: Web/HTTP/Headers/Want-Content-Digest
 page-type: http-header
-spec-urls: https://datatracker.ietf.org/doc/html/rfc9530
+spec-urls: https://datatracker.ietf.org/doc/html/rfc9530#section-4
 ---
 
 {{HTTPSidebar}}
 
-The HTTP **`Want-Content-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates that the recipient should send a {{HTTPHeader("Content-Digest")}} header.
-It is the `Content-` analogue of {{HTTPHeader("Want-Repr-Digest")}}.
+The HTTP **`Want-Content-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates a preference for the recipient to send a {{HTTPHeader("Content-Digest")}} integrity header in messages associated with the request URI and representation metadata.
+
+The header includes hashing algorithm preferences that the recipient can use in subsequent messages.
+The preferences only serve as a hint, and the recipient may ignore the algorithm choices, or the integrity headers entirely.
+
+Some implementations may send unsolicited `Content-Digest` headers without requiring a `Want-Content-Digest` header in a previous message.
 
 <table class="properties">
   <tbody>
@@ -26,15 +30,15 @@ It is the `Content-` analogue of {{HTTPHeader("Want-Repr-Digest")}}.
 ## Syntax
 
 ```http
-Want-Content-Digest: <algorithm>=<preference>
+Want-Content-Digest: <digest-algorithm>=<preference>
 ```
 
 ## Directives
 
-`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).
-
-- `<algorithm>`
-  - : For permissible digest algorithms see {{HTTPHeader("Repr-Digest")}}.
+- `<digest-algorithm>`
+  - : The algorithm used to create a digest of the message content.
+    Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`.
+    The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`.
 - `<preference>`
   - : An integer from 0 to 9 where `0` means "not acceptable", and the values `1` to `9` convey ascending, relative, weighted preference.
     In contrast to earlier drafts of the specifications, the weighting is _not_ declared via `q` [quality values](/en-US/docs/Glossary/Quality_values).
@@ -69,3 +73,4 @@ Developers can set and get HTTP headers using `fetch()` in order to provide appl
 ## See also
 
 - {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Repr-Digest")}}, {{HTTPHeader("Want-Repr-Digest")}} digest headers
+- [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com)

files/en-us/web/http/headers/want-repr-digest/index.md

@@ -2,12 +2,17 @@
 title: Want-Repr-Digest
 slug: Web/HTTP/Headers/Want-Repr-Digest
 page-type: http-header
-spec-urls: https://datatracker.ietf.org/doc/html/rfc9530
+spec-urls: https://datatracker.ietf.org/doc/html/rfc9530#section-4
 ---
 
 {{HTTPSidebar}}
 
-The HTTP **`Want-Repr-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates that the recipient should send a {{HTTPHeader("Repr-Digest")}} header.
+The HTTP **`Want-Repr-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates a preference for the recipient to send a {{HTTPHeader("Repr-Digest")}} integrity header in messages associated with the request URI and representation metadata.
+
+The header includes hashing algorithm preferences that the recipient can use in subsequent messages.
+The preferences only serve as a hint, and the recipient may ignore the algorithm choices, or the integrity headers entirely.
+
+Some implementations may send unsolicited `Repr-Digest` headers without requiring a `Want-Repr-Digest` header in a previous message.
 
 <table class="properties">
   <tbody>
@@ -25,13 +30,15 @@ The HTTP **`Want-Repr-Digest`** {{glossary("request header", "request")}} and {{
 ## Syntax
 
 ```http
-Want-Repr-Digest: <algorithm>=<preference>
+Want-Repr-Digest: <digest-algorithm>=<preference>
 ```
 
 ## Directives
 
-- `<algorithm>`
-  - : For permissible digest algorithms see {{HTTPHeader("Repr-Digest")}}.
+- `<digest-algorithm>`
+  - : The algorithm used to create a digest of the representation.
+    Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`.
+    The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`.
 - `<preference>`
   - : An integer from 0 to 9 where `0` means "not acceptable", and the values `1` to `9` convey ascending, relative, weighted preference.
     In contrast to earlier drafts of the specifications, the weighting is _not_ declared via `q` [quality values](/en-US/docs/Glossary/Quality_values).
@@ -55,3 +62,4 @@ Developers can set and get HTTP headers using `fetch()` in order to provide appl
 ## See also
 
 - {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Repr-Digest")}}, {{HTTPHeader("Want-Content-Digest")}} digest headers
+- [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com)

files/en-us/web/http/headers/x-content-type-options/index.md

@@ -7,15 +7,8 @@ browser-compat: http.headers.X-Content-Type-Options
 
 {{HTTPSidebar}}
 
-The HTTP **`X-Content-Type-Options`** {{Glossary("response header")}} is a marker used by the server to indicate that the [MIME types](/en-US/docs/Web/HTTP/MIME_types) advertised in the {{HTTPHeader("Content-Type")}} headers should be followed and not be changed.
-The header allows you to avoid [MIME type sniffing](/en-US/docs/Web/HTTP/MIME_types#mime_sniffing) by saying that the MIME types are deliberately configured.
-
-This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types.
-Since then, other browsers have introduced it, even if their MIME sniffing algorithms were less aggressive.
-
-Starting with Firefox 72, top-level documents also avoid MIME sniffing (if {{HTTPHeader("Content-type")}} is provided).
-This can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than `text/html`.
-Make sure to set both headers correctly.
+The HTTP **`X-Content-Type-Options`** {{Glossary("response header")}} indicates that the [MIME types](/en-US/docs/Web/HTTP/MIME_types) advertised in the {{HTTPHeader("Content-Type")}} headers should be respected and not changed.
+The header allows you to avoid [MIME type sniffing](/en-US/docs/Web/HTTP/MIME_types#mime_sniffing) by specifying that the MIME types are deliberately configured.
 
 Site security testers usually expect this header to be set.
 
@@ -49,6 +42,15 @@ X-Content-Type-Options: nosniff
     `style` and the MIME type is not `text/css`,
     or of type `script` and the MIME type is not a [JavaScript MIME type](https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type).
 
+## Description
+
+This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types.
+Since then, other browsers have introduced it, even if their MIME sniffing algorithms were less aggressive.
+
+Starting with Firefox 72, top-level documents also avoid MIME sniffing (if {{HTTPHeader("Content-type")}} is provided).
+This can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than `text/html`.
+Both headers should be set correctly to avoid this.
+
 ## Specifications
 
 {{Specifications}}

files/en-us/web/http/headers/x-dns-prefetch-control/index.md

@@ -9,10 +9,10 @@ browser-compat: http.headers.X-DNS-Prefetch-Control
 
 {{HTTPSidebar}}{{Non-standard_header}}
 
-The HTTP **`X-DNS-Prefetch-Control`** {{Glossary("response header")}} controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.
+The HTTP **`X-DNS-Prefetch-Control`** {{Glossary("response header")}} controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.
 
-This prefetching is performed in the background, so that the {{glossary("DNS")}} is likely to have been resolved by the time the referenced items are needed.
-This reduces latency when the user clicks a link.
+The intention is that prefetching is performed in the background so that the {{glossary("DNS")}} resolution is complete by the time the referenced items are needed by the browser.
+This reduces latency when the user clicks a link, for example.
 
 <table class="properties">
   <tbody>
@@ -37,11 +37,9 @@ X-DNS-Prefetch-Control: off
 ### Directives
 
 - `on`
-  - : Enables DNS prefetching. This is what browsers do, if they support the feature, when
-    this header is not present
+  - : Enables DNS prefetching. This is what browsers do if they support the feature when this header is not present.
 - `off`
-  - : Disables DNS prefetching. This is useful if you don't control the link on the pages,
-    or know that you don't want to leak information to these domains.
+  - : Disables DNS prefetching. This is useful if you don't control the link on the pages or know that you don't want to leak information to these domains.
 
 ## Description