diff --git a/files/en-us/glossary/source_map/index.md b/files/en-us/glossary/source_map/index.md
new file mode 100644
index 000000000000000..b7baf1643909194
--- /dev/null
+++ b/files/en-us/glossary/source_map/index.md
@@ -0,0 +1,20 @@
+---
+title: Source map
+slug: Glossary/Source_map
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+A **source map** is a file that maps between minified or transformed code received by the browser and its original unmodified form, allowing the original code to be reconstructed and used when debugging.
+
+The JavaScript code executed by the browser has often been transformed in some way from the original source created by a developer.
+For example, sources are often combined and minified to make delivering them from the server more efficient.
+Additionally, JavaScript running on a page is often machine-generated, such as compiled from a language like TypeScript.
+
+In these situations, debugging the original source is much easier than the source in the transformed state that the browser has downloaded.
+
+## See also
+
+- HTTP {{HTTPHeader("SourceMap")}} response header
+- [Firefox Developer Tools: using a source map](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html)
diff --git a/files/en-us/web/api/ndefrecord/lang/index.md b/files/en-us/web/api/ndefrecord/lang/index.md
index cc3d251e4df4f92..5c8bad51daa18d0 100644
--- a/files/en-us/web/api/ndefrecord/lang/index.md
+++ b/files/en-us/web/api/ndefrecord/lang/index.md
@@ -38,4 +38,4 @@ A string.
 ## See also
 
 - [HTML `lang` attribute](/en-US/docs/Web/HTML/Global_attributes/lang), that declares content language of the document or its elements
-- HTTP headers that declare content language: {{HTTPHeader("Content-Language")}} and {{HTTPHEader("Accept-Language")}}
+- HTTP headers that declare content language: {{HTTPHeader("Content-Language")}} and {{HTTPHeader("Accept-Language")}}
diff --git a/files/en-us/web/http/headers/connection/index.md b/files/en-us/web/http/headers/connection/index.md
index b62442b25de24a6..f803c8c88cf919d 100644
--- a/files/en-us/web/http/headers/connection/index.md
+++ b/files/en-us/web/http/headers/connection/index.md
@@ -70,3 +70,8 @@ Connection: close
 ## Browser compatibility
 
 {{Compat}}
+
+## See also
+
+- [Connection management in HTTP/1.x](/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x)
+- [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism)
diff --git a/files/en-us/web/http/headers/forwarded/index.md b/files/en-us/web/http/headers/forwarded/index.md
index c3b77f6a946f8d9..54cfbe9fc55a142 100644
--- a/files/en-us/web/http/headers/forwarded/index.md
+++ b/files/en-us/web/http/headers/forwarded/index.md
@@ -14,7 +14,7 @@ The header is optional and may be added to, modified, or removed, by any of the
 
 This header is used for debugging, statistics, and generating location-dependent content.
 By design, it exposes privacy sensitive information, such as the IP address of the client.
-Therefore, the user's privacy must be kept in mind when deploying this header.
+Therefore, the user's privacy must be kept in mind when using 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.
 
diff --git a/files/en-us/web/http/headers/index.md b/files/en-us/web/http/headers/index.md
index 80930c93da6f119..648da5763cf0ce0 100644
--- a/files/en-us/web/http/headers/index.md
+++ b/files/en-us/web/http/headers/index.md
@@ -316,7 +316,7 @@ Headers used by the [WebSockets API](/en-US/docs/Web/API/WebSockets_API) in the
 - `Service-Worker-Allowed`
   - : Used to remove the [path restriction](/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#why_is_my_service_worker_failing_to_register) by including this header [in the response of the Service Worker script](https://w3c.github.io/ServiceWorker/#service-worker-script-response).
 - {{HTTPHeader("SourceMap")}}
-  - : Links generated code to a [source map](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html).
+  - : Links to a {{Glossary("source map")}} so that debuggers can step through original source code instead of generated or transformed code.
 - {{HTTPHeader("Upgrade")}}
   - : This HTTP/1.1 (only) header can be used to upgrade an already established client/server connection to a different protocol (over the same transport protocol). For example, it can be used by a client to upgrade a connection from HTTP 1.1 to HTTP 2.0, or an HTTP or HTTPS connection into a WebSocket.
 - {{HTTPHeader("Priority")}}
diff --git a/files/en-us/web/http/headers/no-vary-search/index.md b/files/en-us/web/http/headers/no-vary-search/index.md
index d27f5187efdc27f..a2ab1fe58514c7b 100644
--- a/files/en-us/web/http/headers/no-vary-search/index.md
+++ b/files/en-us/web/http/headers/no-vary-search/index.md
@@ -132,3 +132,7 @@ No-Vary-Search: params, except=("id")
 ## Browser compatibility
 
 {{Compat}}
+
+## See also
+
+- [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header
diff --git a/files/en-us/web/http/headers/origin-agent-cluster/index.md b/files/en-us/web/http/headers/origin-agent-cluster/index.md
index 2ba3eee931ee8b0..39a4819381e58c0 100644
--- a/files/en-us/web/http/headers/origin-agent-cluster/index.md
+++ b/files/en-us/web/http/headers/origin-agent-cluster/index.md
@@ -9,10 +9,37 @@ browser-compat: http.headers.Origin-Agent-Cluster
 
 {{HTTPSidebar}}{{SeeCompatTable}}
 
-The HTTP **`Origin-Agent-Cluster`** {{Glossary("response header")}} is used to request that the associated {{domxref("Document")}} should be placed in an _origin-keyed [agent cluster](https://tc39.es/ecma262/#sec-agent-clusters)_. This means that operating system resources (for example, the operating system process) used to evaluate the document should be shared only with other documents from the same {{glossary("origin")}}.
+The HTTP **`Origin-Agent-Cluster`** {{Glossary("response header")}} is used to request that the associated {{domxref("Document")}} should be placed in an **origin-keyed [agent cluster](https://tc39.es/ecma262/#sec-agent-clusters)**. This means that operating system resources (for example, the operating system process) used to evaluate the document should be shared only with other documents from the same {{glossary("origin")}}.
 
 The effect of this is that a resource-intensive document will be less likely to degrade the performance of documents from other origins.
 
+<table class="properties">
+  <tbody>
+    <tr>
+      <th scope="row">Header type</th>
+      <td>{{Glossary("Response header")}}</td>
+    </tr>
+    <tr>
+      <th scope="row">{{Glossary("Forbidden header name")}}</th>
+      <td>No</td>
+    </tr>
+  </tbody>
+</table>
+
+## Syntax
+
+```http
+Origin-Agent-Cluster: <boolean>
+```
+
+### Directives
+
+- `<boolean>`
+  - : `?1` indicates that the associated {{domxref("Document")}} should be placed in an origin-keyed agent cluster.
+    Values other than `?1` are ignored (e.g., the `?0` structured field for false).
+
+## Description
+
 Modern web browsers have a multiprocess architecture in which pages from different origins can run in different operating system processes. This is important for performance, because it means that a resource-intensive page will not have as much of an impact on other pages that the user has open.
 
 However, browsers can't as a general rule run {{glossary("site", "same-site")}}, {{glossary("origin", "cross-origin")}} pages in different processes, because of certain DOM APIs that depend on same-site, cross-origin communication. For example, by default, pages from the following two origins will share the same operating system resources:
@@ -41,31 +68,6 @@ The browser will ensure that all pages from a given origin are either origin-key
 
 To avoid this kind of unpredictable situation, you should set this header for all pages from a given origin, or none of them.
 
-<table class="properties">
-  <tbody>
-    <tr>
-      <th scope="row">Header type</th>
-      <td>{{Glossary("Response header")}}</td>
-    </tr>
-    <tr>
-      <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>No</td>
-    </tr>
-  </tbody>
-</table>
-
-## Syntax
-
-```http
-Origin-Agent-Cluster: <boolean>
-```
-
-### Directives
-
-- `<boolean>`
-  - : `?1` indicates that the associated {{domxref("Document")}} should be placed in an origin-keyed agent cluster.
-    Values other than `?1` are ignored (e.g., the `?0` structured field for false).
-
 ## Examples
 
 ```http
diff --git a/files/en-us/web/http/headers/permissions-policy/index.md b/files/en-us/web/http/headers/permissions-policy/index.md
index 28e50ce5bc5b3c6..09a8e6b7b234846 100644
--- a/files/en-us/web/http/headers/permissions-policy/index.md
+++ b/files/en-us/web/http/headers/permissions-policy/index.md
@@ -38,16 +38,22 @@ Permissions-Policy: <directive>=<allowlist>
 
   - : An allowlist is a list of origins that takes one or more of the following values contained in parentheses, separated by spaces:
 
-    - `*`: The feature will be allowed in this document, and all nested browsing contexts (`<iframe>`s) regardless of their origin.
-    - `()` (empty allowlist): The feature is disabled in top-level and nested browsing contexts. The equivalent for `<iframe>` `allow` attributes is `'none'`.
-    - `self`: The feature will be allowed in this document, and in all nested browsing contexts (`<iframe>`s) in the same origin only. The feature is not allowed in cross-origin documents in nested browsing contexts. `self` can be considered shorthand for `https://your-site.example.com`. The equivalent for `<iframe>` `allow` attributes is `self`.
-    - `src`: The feature will be allowed in this `<iframe>`, as long as the document loaded into it comes from the same origin as the URL in its {{HTMLElement('iframe','src','#Attributes')}} attribute. This value is only used in the `<iframe>` `allow` attribute, and is the _default_ `allowlist` value in `<iframe>`s.
-    - `"<origin>"`: The feature is allowed for specific origins (for example, `"https://a.example.com"`). Origins should be separated by spaces. Note that origins in `<iframe>` allow attributes are not quoted.
+    - `*` (wildcard)
+      - : The feature will be allowed in this document, and all nested browsing contexts (`<iframe>`s) regardless of their origin.
+    - `()` (empty allowlist)
+      - : The feature is disabled in top-level and nested browsing contexts. The equivalent for `<iframe>` `allow` attributes is `'none'`.
+    - `self`
+      - : The feature will be allowed in this document, and in all nested browsing contexts (`<iframe>`s) in the same origin only. The feature is not allowed in cross-origin documents in nested browsing contexts. `self` can be considered shorthand for `https://your-site.example.com`. The equivalent for `<iframe>` `allow` attributes is `self`.
+    - `src`
+      - : The feature will be allowed in this `<iframe>`, as long as the document loaded into it comes from the same origin as the URL in its {{HTMLElement('iframe','src','#Attributes')}} attribute. This value is only used in the `<iframe>` `allow` attribute, and is the _default_ `allowlist` value in `<iframe>`s.
+    - `"<origin>"`
+      - : The feature is allowed for specific origins (for example, `"https://a.example.com"`). Origins should be separated by spaces. Note that origins in `<iframe>` allow attributes are not quoted.
 
     The values `*` and `()` may only be used on their own, while `self` and `src` may be used in combination with one or more origins.
 
     > [!NOTE]
-    > Directives have a default allowlist, which is always one of `*`, `self`, or `none` for the `Permissions-Policy` HTTP header, and governs the default behavior if they are not explicitly listed in a policy. These are specified on the individual [directive reference pages](#directives). For `<iframe>` `allow` attributes, the default behavior is always `src`.
+    > Directives have a default allowlist, which is always one of `*`, `self`, or `none` for the `Permissions-Policy` HTTP header, and governs the default behavior if they are not explicitly listed in a policy.
+    > These are specified on the individual [directive reference pages](#directives). For `<iframe>` `allow` attributes, the default behavior is always `src`.
 
 Where supported, you can include wildcards in Permissions Policy origins. This means that instead of having to explicitly specify several different subdomains in an allowlist, you can specify them all in a single origin with a wildcard.
 
diff --git a/files/en-us/web/http/headers/proxy-authenticate/index.md b/files/en-us/web/http/headers/proxy-authenticate/index.md
index 32e7812814b15bf..8bdfe7ee2a52ce4 100644
--- a/files/en-us/web/http/headers/proxy-authenticate/index.md
+++ b/files/en-us/web/http/headers/proxy-authenticate/index.md
@@ -25,25 +25,69 @@ It is sent in a {{HTTPStatus("407", "407 Proxy Authentication Required")}} respo
 
 ## Syntax
 
+A comma-separated list of one or more authentication challenges:
+
 ```http
-Proxy-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <challenge>
+```
+
+Where a `<challenge>` is comprised of an `<auth-scheme>`, followed by an optional `<token68>` or a comma-separated list of `<auth-params>`:
+
+```plain
+challenge = <auth-scheme> <auth-param>, …, <auth-paramN>
+challenge = <auth-scheme> <token68>
+```
+
+For example:
+
+```http
+Proxy-Authenticate: <auth-scheme>
+Proxy-Authenticate: <auth-scheme> token68
+Proxy-Authenticate: <auth-scheme> auth-param1=param-token1
+Proxy-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN
+```
+
+The presence of a `token68` or authentication parameters depends on the selected `<auth-scheme>`.
+For example, [Basic authentication](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme) requires a `<realm>`, and allows for optional use of `charset` key, but does not support a `token68`:
+
+```http
+Proxy-Authenticate: Basic realm="Dev", charset="UTF-8"
 ```
 
 ## Directives
 
-- `<type>`
-  - : [Authentication type](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).
-    A common type is ["Basic"](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme).
-    IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml).
-- `realm=<realm>`
-  - : A description of the protected area, the realm. If no realm is specified, clients often display a formatted host name instead.
+- `<auth-scheme>`
+  - : A case-insensitive token indicating the [Authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes) used.
+    Some of the more common types are [`Basic`](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.
+    IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), but there are other schemes offered by host services.
+- `<auth-param>` {{optional_inline}}
+  - : An authentication parameter whose format depends on the `<auth-scheme>`.
+    `<realm>` is described below as it's a common authentication parameter among many auth schemes.
+    - `<realm>` {{optional_inline}}
+      - : The string `realm` followed by `=` and a quoted string describing a protected area, for example `realm="staging environment"`.
+        A realm allows a server to partition the areas it protects (if supported by a scheme that allows such partitioning).
+        Some clients show this value to the user to inform them about which particular credentials are required — though most browsers stopped doing so to counter phishing.
+        The only reliably supported character set for this value is `us-ascii`.
+        If no realm is specified, clients often display a formatted hostname instead.
+- `<token68>` {{optional_inline}}
+  - : A token that may be useful for some schemes.
+    The token allows the 66 unreserved URI characters plus a few others.
+    It can hold a {{glossary("base64")}}, base64url, base32, or base16 (hex) encoding, with or without padding, but excluding whitespace.
+    The `token68` alternative to auth-param lists is supported for consistency with legacy authentication schemes.
+
+Generally, you will need to check the relevant specifications for the authentication parameters needed for each `<auth-scheme>`.
+
+> [!NOTE]
+> See {{HTTPHeader("WWW-Authenticate")}} for more details on authentication parameters.
 
 ## Examples
 
-```http
-Proxy-Authenticate: Basic
+### Proxy-Authenticate Basic auth
 
-Proxy-Authenticate: Basic realm="Access to the internal site"
+The following response indicates a Basic auth scheme is required with a realm:
+
+```http
+Proxy-Authenticate: Basic realm="Staging server"
 ```
 
 ## Specifications
@@ -56,7 +100,7 @@ Proxy-Authenticate: Basic realm="Access to the internal site"
 
 ## See also
 
+- {{HTTPHeader("WWW-Authenticate")}}
 - [HTTP authentication](/en-US/docs/Web/HTTP/Authentication)
 - {{HTTPHeader("Authorization")}}, {{HTTPHeader("Proxy-Authorization")}}
-- {{HTTPHeader("WWW-Authenticate")}}
 - {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}
diff --git a/files/en-us/web/http/headers/proxy-authorization/index.md b/files/en-us/web/http/headers/proxy-authorization/index.md
index 906338feaca78d8..8c2bde547eb6f40 100644
--- a/files/en-us/web/http/headers/proxy-authorization/index.md
+++ b/files/en-us/web/http/headers/proxy-authorization/index.md
@@ -31,10 +31,15 @@ Proxy-Authorization: <auth-scheme> <credentials>
 ## Directives
 
 - `<auth-scheme>`
-  - : Token indicating the [authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes), such as `Basic`, `Bearer`, etc.
-    The [IANA registry of Authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml) maintains a full list of available types.
+  - : A case-insensitive token indicating the [Authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes) used.
+    Some of the more common types are [`Basic`](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.
+    IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), but there are other schemes offered by host services.
 - `<credentials>`
   - : Credentials use for the authentication scheme.
+    Generally, you will need to check the relevant specifications for the format.
+
+> [!NOTE]
+> See {{HTTPHeader("Authorization")}} for more details.
 
 ## Examples
 
diff --git a/files/en-us/web/http/headers/range/index.md b/files/en-us/web/http/headers/range/index.md
index 1a0f46c7766a0a8..0aa40362beef98e 100644
--- a/files/en-us/web/http/headers/range/index.md
+++ b/files/en-us/web/http/headers/range/index.md
@@ -13,7 +13,7 @@ If the server sends back ranges, it uses the {{HTTPStatus("206", "206 Partial Co
 If the ranges are invalid, the server returns the {{HTTPStatus("416", "416 Range Not Satisfiable")}} error.
 
 A server that doesn't support range requests may ignore the `Range` header and return the whole resource with a {{HTTPStatus("200")}} status code.
-Older browsers used a response header of {{HTTPHeader("Accept-Ranges", "Accept-Ranges: none")}} to disable features like 'pause' or 'resume' in download managers, but since ignoring the `Range` header has the same effect as `Accept-Ranges: none`, the header is rarely used in this way.
+Older browsers used a response header of {{HTTPHeader("Accept-Ranges", "Accept-Ranges: none")}} to disable features like 'pause' or 'resume' in download managers, but since a server ignoring the `Range` header has the same meaning as responding with `Accept-Ranges: none`, the header is rarely used in this way.
 
 Currently only [`bytes` units are registered](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units) which are _offsets_ (zero-indexed & inclusive).
 If the requested data has a [content coding](/en-US/docs/Web/HTTP/Headers/Content-Encoding) applied, each byte range represents the encoded sequence of bytes, not the bytes that would be obtained after decoding.
@@ -38,7 +38,7 @@ The header is a [CORS-safelisted request header](/en-US/docs/Glossary/CORS-safel
 ```http
 Range: <unit>=<range-start>-
 Range: <unit>=<range-start>-<range-end>
-Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, …
+Range: <unit>=<range-start>-<range-end>, …, <range-startN>-<range-endN>
 Range: <unit>=-<suffix-length>
 ```
 
diff --git a/files/en-us/web/http/headers/reporting-endpoints/index.md b/files/en-us/web/http/headers/reporting-endpoints/index.md
index 584d9ac6468b84d..baa9102b4f9312b 100644
--- a/files/en-us/web/http/headers/reporting-endpoints/index.md
+++ b/files/en-us/web/http/headers/reporting-endpoints/index.md
@@ -42,7 +42,7 @@ For more details on setting up CSP reporting, see the [Content Security Policy (
 
 ```http
 Reporting-Endpoints: <endpoint>
-Reporting-Endpoints: <endpoint>, <endpoint>
+Reporting-Endpoints: <endpoint>, …, <endpointN>
 ```
 
 - `<endpoint>`
diff --git a/files/en-us/web/http/headers/repr-digest/index.md b/files/en-us/web/http/headers/repr-digest/index.md
index ec85527ff89bc67..8da7a683fc08556 100644
--- a/files/en-us/web/http/headers/repr-digest/index.md
+++ b/files/en-us/web/http/headers/repr-digest/index.md
@@ -35,7 +35,7 @@ A {{HTTPHeader("Content-Digest")}} applies to the content of a specific message,
 Repr-Digest: <digest-algorithm>=<digest-value>
 
 // Multiple digest algorithms
-Repr-Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>
+Repr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>
 ```
 
 ## Directives
diff --git a/files/en-us/web/http/headers/server-timing/index.md b/files/en-us/web/http/headers/server-timing/index.md
index 362aa578218fcdd..92349e3a43639d4 100644
--- a/files/en-us/web/http/headers/server-timing/index.md
+++ b/files/en-us/web/http/headers/server-timing/index.md
@@ -7,7 +7,8 @@ browser-compat: http.headers.Server-Timing
 
 {{HTTPSidebar}}
 
-The **`Server-Timing`** header communicates one or more metrics and descriptions for a given request-response cycle. It is used to surface any backend server timing metrics (e.g. database read/write, CPU time, file system access, etc.) in the developer tools in the user's browser or in the {{domxref("PerformanceServerTiming")}} interface.
+The HTTP **`Server-Timing`** {{Glossary("response header")}} communicates one or more performance metrics about the request-response cycle to the user agent.
+It is used to surface backend server timing metrics (for example, database read/write, CPU time, file system access, etc.) in the developer tools in the user's browser or in the {{domxref("PerformanceServerTiming")}} interface.
 
 <table class="properties">
   <tbody>
@@ -17,55 +18,98 @@ The **`Server-Timing`** header communicates one or more metrics and descriptions
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
 ## Syntax
 
-The syntax of the `Server-Timing` header allows you to communicate metrics in different ways: server metric name only, metric with value, metric with value and description, and metric with description.
-
-This header can contain one or more metrics, separated by commas. Each metric has a name, an optional duration, and an optional description. These components are separated by semi-colons.
+```http
+// A single metric
+Server-Timing: <timing-metric>
 
-The duration component consists of the string `"dur"`, followed by `"="`, followed by the value, like `"dur=23.2"`.
-The description component consists of the string `"desc"`, followed by `"="`, followed by the value, like `"desc=DB lookup"`.
+// Multiple metrics as a comma-separated list
+Server-Timing: <timing-metric>, …, <timing-metricN>
+```
 
-The specification advises that names and descriptions should be kept as short as possible (use abbreviations and omit optional values where possible) to minimize the HTTP overhead.
+A `<timing-metric>` has a name, and may include an optional duration and an optional description.
+For example:
 
 ```http
-// Single metric without value
+// A metric with a name only
 Server-Timing: missedCache
 
-// Single metric with value
+// A metric with a duration
 Server-Timing: cpu;dur=2.4
 
-// Single metric with description and value
+// A metric with a description and duration
 Server-Timing: cache;desc="Cache Read";dur=23.2
 
-// Two metrics with value
+// Two metrics with duration values
 Server-Timing: db;dur=53, app;dur=47.2
-
-// Server-Timing as trailer
-Trailer: Server-Timing
---- response body ---
-Server-Timing: total;dur=123.4
 ```
 
-## Privacy and security
+## Directives
+
+- `<timing-metric>`
+  - : A comma-separated list of one or more metrics with the following components separated by semi-colons:
+    - `<name>`
+      - : A name token (no spaces or special characters) for the metric that is implementation-specific or defined by the server, like `cacheHit`.
+    - `<duration>` {{optional_inline}}
+      - : A duration as the string `dur`, followed by `=`, followed by a value, like `dur=23.2`.
+    - `<description>` {{optional_inline}}
+      - : A description as the string `desc`, followed by `=`, followed by a value as a token or a quoted string, like `desc=prod` or `desc="DB lookup"`.
 
-The `Server-Timing` header may expose potentially sensitive application and infrastructure information. Consider to control which metrics are returned when and to whom on the server side. For example, you could only show metrics to authenticated users and nothing to the public.
+Names and descriptions should be kept as short as possible (for example, use abbreviations and omit optional values) to minimize HTTP data overhead.
 
-## PerformanceServerTiming interface
+## Description
+
+### Privacy and security
+
+The `Server-Timing` header may expose potentially sensitive application and infrastructure information.
+Decide which metrics to send, when to send them, and who should see them based on the use case.
+For example, you may decide to only show metrics to authenticated users and nothing on public responses.
+
+### PerformanceServerTiming interface
 
 In addition to having `Server-Timing` header metrics appear in the developer tools of the browser, the {{domxref("PerformanceServerTiming")}} interface enables tools to automatically collect and process metrics from JavaScript. This interface is restricted to the same origin, but you can use the {{HTTPHeader("Timing-Allow-Origin")}} header to specify the domains that are allowed to access the server metrics. The interface is only available in secure contexts (HTTPS) in some browsers.
 
-The components of the `Server-Timing` header map to the {{domxref("PerformanceServerTiming")}} properties like this:
+The components of the `Server-Timing` header map to the {{domxref("PerformanceServerTiming")}} properties as follows:
 
 - `"name"` -> {{domxref("PerformanceServerTiming.name")}}
 - `"dur"` -> {{domxref("PerformanceServerTiming.duration")}}
 - `"desc"` -> {{domxref("PerformanceServerTiming.description")}}
 
+## Examples
+
+### Sending a metric using the Server-Timing header
+
+The following response includes a metric `custom-metric` with a duration of `123.45` milliseconds, and a description of "My custom metric":
+
+```http
+Server-Timing: custom-metric;dur=123.45;desc="My custom metric"
+```
+
+### Server-Timing as HTTP trailer
+
+In the following response, the {{HTTPHeader("Trailer")}} header is used to indicate that a `Server-Timing` header will follow the response body.
+A metric `custom-metric` with a duration of `123.4` milliseconds is sent.
+
+```http
+HTTP/1.1 200 OK
+Transfer-Encoding: chunked
+Trailer: Server-Timing
+
+--- response body ---
+Server-Timing: custom-metric;dur=123.4
+```
+
+> [!WARNING]
+> Only the browser's DevTools can use the `Server-Timing` header as a HTTP trailer to display information in the Network -> Timings tab.
+> The Fetch API cannot access HTTP trailers.
+> See [Browser compatibility](#browser_compatibility) for more information.
+
 ## Specifications
 
 {{Specifications}}
@@ -77,3 +121,4 @@ The components of the `Server-Timing` header map to the {{domxref("PerformanceSe
 ## See also
 
 - {{domxref("PerformanceServerTiming")}}
+- {{HTTPHeader("Trailer")}} header
diff --git a/files/en-us/web/http/headers/server/index.md b/files/en-us/web/http/headers/server/index.md
index 39c448e2c78c356..b1b1e2240a8849e 100644
--- a/files/en-us/web/http/headers/server/index.md
+++ b/files/en-us/web/http/headers/server/index.md
@@ -7,7 +7,7 @@ browser-compat: http.headers.Server
 
 {{HTTPSidebar}}
 
-The **`Server`** header describes the software used by the origin server that handled the request and generated a response.
+The HTTP **`Server`** {{Glossary("response header")}} describes the software used by the origin server that handled the request and generated a response.
 
 The benefits of advertising the server type and version via this header are that it helps with analytics and identifying how widespread specific interoperability issues are.
 Historically, clients have used the server version information to avoid known limitations, such as inconsistent support for [range requests](/en-US/docs/Web/HTTP/Range_requests) in specific software versions.
@@ -27,7 +27,7 @@ In general, a more robust approach to server security is to ensure software is r
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
diff --git a/files/en-us/web/http/headers/service-worker-navigation-preload/index.md b/files/en-us/web/http/headers/service-worker-navigation-preload/index.md
index 179299d34de0c87..729fa7fb77b3a7c 100644
--- a/files/en-us/web/http/headers/service-worker-navigation-preload/index.md
+++ b/files/en-us/web/http/headers/service-worker-navigation-preload/index.md
@@ -7,10 +7,10 @@ browser-compat: http.headers.Service-Worker-Navigation-Preload
 
 {{HTTPSidebar}}
 
-The **`Service-Worker-Navigation-Preload`** request header indicates that the request was the result of a {{domxref("Window/fetch", "fetch()")}} operation made during service worker navigation preloading.
+The HTTP **`Service-Worker-Navigation-Preload`** {{Glossary("request header")}} indicates that the request was the result of a {{domxref("Window/fetch", "fetch()")}} operation made during service worker navigation preloading.
 It allows a server to respond with a different resource than for a normal `fetch()`.
 
-If a different response may result from setting this header, the server must set `Vary: Service-Worker-Navigation-Preload` to ensure that the different responses are cached.
+If a different response may result from setting this header, the server must include a {{HTTPHeader("Vary", "Vary: Service-Worker-Navigation-Preload")}} header in responses to ensure that different responses are cached.
 
 For more information see {{domxref("NavigationPreloadManager.setHeaderValue()")}} (and {{domxref("NavigationPreloadManager")}}).
 
@@ -22,7 +22,7 @@ For more information see {{domxref("NavigationPreloadManager.setHeaderValue()")}
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -42,7 +42,9 @@ Service-Worker-Navigation-Preload: <value>
 
 ## Examples
 
-The header below is sent by default.
+### Service worker navigation preloading headers
+
+The following request header is sent by default in navigation preload requests:
 
 ```http
 Service-Worker-Navigation-Preload: true
@@ -62,3 +64,8 @@ Service-Worker-Navigation-Preload: json_fragment1
 ## Browser compatibility
 
 {{Compat}}
+
+## See also
+
+- [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header
+- [Service Worker API](/en-US/docs/Web/API/Service_Worker_API)
diff --git a/files/en-us/web/http/headers/set-cookie/index.md b/files/en-us/web/http/headers/set-cookie/index.md
index 9896d2554904dcb..e10ddfd66097f78 100644
--- a/files/en-us/web/http/headers/set-cookie/index.md
+++ b/files/en-us/web/http/headers/set-cookie/index.md
@@ -7,11 +7,11 @@ browser-compat: http.headers.Set-Cookie
 
 {{HTTPSidebar}}
 
-The **`Set-Cookie`** HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later.
-To send multiple cookies, multiple **`Set-Cookie`** headers should be sent in the same response.
+The HTTP **`Set-Cookie`** {{Glossary("response header")}} is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later.
+To send multiple cookies, multiple `Set-Cookie` headers should be sent in the same response.
 
 > [!WARNING]
-> Browsers block frontend JavaScript code from accessing the `Set-Cookie` header, as required by the Fetch spec, which defines `Set-Cookie` as a [forbidden response-header name](https://fetch.spec.whatwg.org/#forbidden-response-header-name) that [must be filtered out](https://fetch.spec.whatwg.org/#ref-for-forbidden-response-header-name%E2%91%A0) from any response exposed to frontend code.
+> Browsers block frontend JavaScript code from accessing the `Set-Cookie` header, as required by the Fetch spec, which defines `Set-Cookie` as a [forbidden response header name](https://fetch.spec.whatwg.org/#forbidden-response-header-name) that [must be filtered out](https://fetch.spec.whatwg.org/#ref-for-forbidden-response-header-name%E2%91%A0) from any response exposed to frontend code.
 >
 > When a [Fetch API](/en-US/docs/Web/API/Fetch_API/Using_Fetch) or [XMLHttpRequest API](/en-US/docs/Web/API/XMLHttpRequest_API) request [uses CORS](/en-US/docs/Web/HTTP/CORS#what_requests_use_cors), browsers will ignore `Set-Cookie` headers present in the server's response unless the request includes credentials. Visit [Using the Fetch API - Including credentials](/en-US/docs/Web/API/Fetch_API/Using_Fetch#including_credentials) and the [XMLHttpRequest article](/en-US/docs/Web/API/XMLHttpRequest_API) to learn how to include credentials.
 
@@ -25,11 +25,11 @@ For more information, see the guide on [Using HTTP cookies](/en-US/docs/Web/HTTP
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden response header name")}}</th>
-      <td>yes</td>
+      <td>Yes</td>
     </tr>
   </tbody>
 </table>
@@ -145,6 +145,10 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnl
       - : Means that the cookie is not sent on cross-site requests, such as on requests to load images or frames, but is sent when a user is navigating to the origin site from an external site (for example, when following a link).
         This is the default behavior if the `SameSite` attribute is not specified.
 
+        > [!WARNING]
+        > Not all browsers set `SameSite=Lax` by default.
+        > See [Browser compatibility](#browser_compatibility) for details.
+
     - `None`
 
       - : Means that the browser sends the cookie with both cross-site and same-site requests.
@@ -167,15 +171,16 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnl
   - : Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to [man-in-the-middle](/en-US/docs/Glossary/MitM) attacks.
 
     > [!NOTE]
-    > Do not assume that `Secure` prevents all access to sensitive information in cookies (session keys, login details, etc.). Cookies with this attribute can still be read/modified either with access to the client's hard disk or from JavaScript if the `HttpOnly` cookie attribute is not set.
+    > Do not assume that `Secure` prevents all access to sensitive information in cookies (session keys, login details, etc.).
+    > Cookies with this attribute can still be read/modified either with access to the client's hard disk or from JavaScript if the `HttpOnly` cookie attribute is not set.
     >
-    > Insecure sites (`http:`) cannot set cookies with the `Secure` attribute (since Chrome 52 and Firefox 52). The `https:` requirements are ignored when the `Secure` attribute is set by localhost (since Chrome 89 and Firefox 75).
+    > Insecure sites (`http:`) cannot set cookies with the `Secure` attribute. The `https:` requirements are ignored when the `Secure` attribute is set by localhost.
 
 ## Examples
 
 ### Session cookie
 
-**Session cookies** are removed when the client shuts down. Cookies are session cookies if they do not specify the `Expires` or `Max-Age` attribute.
+Session cookies are removed when the client shuts down. Cookies are session cookies if they do not specify the `Expires` or `Max-Age` attribute.
 
 ```http
 Set-Cookie: sessionId=38afes7a8
@@ -183,7 +188,7 @@ Set-Cookie: sessionId=38afes7a8
 
 ### Permanent cookie
 
-**Permanent cookies** are removed at a specific date (`Expires`) or after a specific length of time (`Max-Age`) and not when the client is closed.
+Permanent cookies are removed at a specific date (`Expires`) or after a specific length of time (`Max-Age`) and not when the client is closed.
 
 ```http
 Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
@@ -252,10 +257,6 @@ Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
 
 {{Compat}}
 
-### Compatibility notes
-
-- Starting with Chrome 52 and Firefox 52, insecure sites (`http:`) can't set cookies with the `Secure` attribute anymore.
-
 ## See also
 
 - [HTTP cookies](/en-US/docs/Web/HTTP/Cookies)
diff --git a/files/en-us/web/http/headers/set-login/index.md b/files/en-us/web/http/headers/set-login/index.md
index fb403875de90203..3f3385a398e0780 100644
--- a/files/en-us/web/http/headers/set-login/index.md
+++ b/files/en-us/web/http/headers/set-login/index.md
@@ -9,9 +9,12 @@ browser-compat: http.headers.Set-Login
 
 {{HTTPSidebar}}{{SeeCompatTable}}
 
-The **`Set-Login`** {{Glossary("Response header", "response header")}} is sent by a federated identity provider (IdP) to set its login status — by this, we mean "whether any users are logged into the IdP on the current browser or not". This is stored by the browser and used by the [FedCM API](/en-US/docs/Web/API/FedCM_API) to reduce the number of requests it makes to the IdP (because it does not need to waste time requesting accounts when there are no users logged in to the IdP). It also mitigates [potential timing attacks](https://github.com/w3c-fedid/FedCM/issues/447).
+The HTTP **`Set-Login`** {{Glossary("response header")}} is sent by a federated identity provider (IdP) to set its login status, and indicates whether any users are logged into the IdP on the current browser or not.
+This is stored by the browser and used by the [FedCM API](/en-US/docs/Web/API/FedCM_API) to reduce the number of requests it makes to the IdP as the browser doesn't need to request accounts when there are no users logged in to the IdP.
+It also mitigates [potential timing attacks](https://github.com/w3c-fedid/FedCM/issues/447).
 
-The header may be set on any response resulting from a top-level navigation or a same-origin subresource request on the IdP's origin site — basically, any interaction with the IdP site may result in this header being set, and the login status being stored by the browser.
+The header may be set on any response resulting from a top-level navigation or a same-origin subresource request on the IdP's origin site.
+Any interaction with the IdP site may result in this header being set, and the login status being stored by the browser.
 
 See [Update login status using the Login Status API](/en-US/docs/Web/API/FedCM_API/IDP_integration#update_login_status_using_the_login_status_api) for more information about FedCM login status.
 
@@ -23,7 +26,7 @@ See [Update login status using the Login Status API](/en-US/docs/Web/API/FedCM_A
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -31,20 +34,20 @@ See [Update login status using the Login Status API](/en-US/docs/Web/API/FedCM_A
 ## Syntax
 
 ```http
-Set-Login: status
+Set-Login: <status>
 ```
 
 ## Directives
 
-- `status`
+- `<status>`
 
   - : A string representing the login status to set for the IdP. Possible values are:
 
-    - `"logged-in"`: The IdP has at least one user account signed in.
-    - `"logged-out"`: All IdP user accounts are currently signed out.
+    - `logged-in`: The IdP has at least one user account signed in.
+    - `logged-out`: All IdP user accounts are currently signed out.
 
     > [!NOTE]
-    > Browsers should ignore this header if it contains any other value.
+    > Browsers ignore this header if it contains any other value.
 
 ## Examples
 
diff --git a/files/en-us/web/http/headers/sourcemap/index.md b/files/en-us/web/http/headers/sourcemap/index.md
index 341c6f7b84b557f..876f7fb2c8f7698 100644
--- a/files/en-us/web/http/headers/sourcemap/index.md
+++ b/files/en-us/web/http/headers/sourcemap/index.md
@@ -7,7 +7,9 @@ browser-compat: http.headers.SourceMap
 
 {{HTTPSidebar}}
 
-The **`SourceMap`** [HTTP](/en-US/docs/Web/HTTP) response header links generated code to a [source map](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html), enabling the browser to reconstruct the original source and present the reconstructed original in the debugger.
+The HTTP **`SourceMap`** {{Glossary("response header")}} provides the location of a {{Glossary("source map")}} for the resource.
+
+The HTTP `SourceMap` header has precedence over a source annotation (`sourceMappingURL=path-to-map.js.map`), and if both are present, the header URL is used to resolve the source map file.
 
 <table class="properties">
   <tbody>
@@ -17,7 +19,7 @@ The **`SourceMap`** [HTTP](/en-US/docs/Web/HTTP) response header links generated
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -31,15 +33,25 @@ X-SourceMap: <url> (deprecated)
 
 ### Directives
 
-- \<url>
+- `<url>`
   - : A relative (to the request URL) or absolute URL pointing to a source map file.
 
 ## Examples
 
+### Linking to a source map using the `SourceMap` header
+
+The following response contains an absolute path in the `SourceMap` header.
+
 ```http
+HTTP/1.1 200 OK
+Content-Type: application/javascript
 SourceMap: /path/to/file.js.map
+
+<optimized-javascript>
 ```
 
+Developer tools use the source map to reconstruct the original source from the optimized JavaScript returned in the response, allowing developers to debug the original code rather than the format that has been optimized for sending.
+
 ## Specifications
 
 {{Specifications}}
@@ -50,4 +62,6 @@ SourceMap: /path/to/file.js.map
 
 ## See also
 
+- {{Glossary("Source map")}}
 - [Firefox Developer Tools: using a source map](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html)
+- [What are source maps?](https://web.dev/articles/source-maps) on web.dev (2023)
diff --git a/files/en-us/web/http/headers/speculation-rules/index.md b/files/en-us/web/http/headers/speculation-rules/index.md
index 8520ec5b34ca1ed..333054dfee26001 100644
--- a/files/en-us/web/http/headers/speculation-rules/index.md
+++ b/files/en-us/web/http/headers/speculation-rules/index.md
@@ -9,7 +9,7 @@ browser-compat: http.headers.Speculation-Rules
 
 {{HTTPSidebar}}{{SeeCompatTable}}
 
-The **`Speculation-Rules`** response header provides one or more URLs pointing to text resources containing speculation rule JSON definitions. When the response is an HTML document, these rules will be added to the document's speculation rule set. See the [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) for more information.
+The HTTP **`Speculation-Rules`** {{Glossary("response header")}} provides one or more URLs pointing to text resources containing speculation rule JSON definitions. When the response is an HTML document, these rules will be added to the document's speculation rule set. See the [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) for more information.
 
 The resource file containing the speculation rules JSON can have any valid name and extension, but it must be served with an `application/speculationrules+json` MIME type.
 
@@ -24,7 +24,7 @@ The resource file containing the speculation rules JSON can have any valid name
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -37,18 +37,22 @@ Speculation-Rules: <url-list>
 
 ## Directives
 
-- \<url-list>
+- `<url-list>`
   - : A comma-separated list of URLs pointing to text resources containing speculation rule JSON definitions. The JSON contained in the text files must follow the same rules as that contained inside inline `<script type="speculationrules">` elements. See [Speculation rules JSON representation](/en-US/docs/Web/HTML/Element/script/type/speculationrules#speculation_rules_json_representation) for the syntax reference.
 
 ## Examples
 
-Single speculation rules file reference:
+### Speculation-Rules field with a single file
+
+The following response contains one file reference:
 
 ```http
 Speculation-Rules: "/rules/prefetch.json"
 ```
 
-Multiple speculation rules file references:
+### Speculation-Rules field with multiple files
+
+The following response contains multiple file reference as a comma-separated list:
 
 ```http
 Speculation-Rules: "/rules/prefetch.json","/rules/prerender.json"
diff --git a/files/en-us/web/http/headers/strict-transport-security/index.md b/files/en-us/web/http/headers/strict-transport-security/index.md
index f87569bd2317a9d..be7767bfbaa2b3b 100644
--- a/files/en-us/web/http/headers/strict-transport-security/index.md
+++ b/files/en-us/web/http/headers/strict-transport-security/index.md
@@ -7,10 +7,10 @@ browser-compat: http.headers.Strict-Transport-Security
 
 {{HTTPSidebar}}
 
-The HTTP **`Strict-Transport-Security`** response header (often abbreviated as {{Glossary("HSTS")}}) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.
+The HTTP **`Strict-Transport-Security`** {{Glossary("response header")}} (often abbreviated as {{Glossary("HSTS")}}) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be upgraded to HTTPS.
 
 > [!NOTE]
-> This is more secure than simply configuring a HTTP to HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.
+> This is more secure than configuring a HTTP to HTTPS ({{HTTPStatus("301")}}) redirect on your server, as the initial HTTP connection is still vulnerable to a man-in-the-middle attack.
 
 <table class="properties">
   <tbody>
@@ -20,7 +20,7 @@ The HTTP **`Strict-Transport-Security`** response header (often abbreviated as {
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -45,46 +45,47 @@ Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload
 
 ## Description
 
-If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types `http://www.foo.com/` or even just foo.com.
+If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types `http://www.foo.com/` or even just `foo.com`.
 This creates an opportunity for a man-in-the-middle attack.
 The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.
 
-The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.
+The `Strict-Transport-Security` header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.
 
 > [!NOTE]
 > The `Strict-Transport-Security` header is _ignored_ by the browser when your site has only been accessed using HTTP.
-> Once your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the `Strict-Transport-Security` header.
+> Once your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS-capable and will honor the `Strict-Transport-Security` header.
 > Browsers do this as attackers may intercept HTTP connections to the site and inject or remove the header.
 
-### An example scenario
+### Strict Transport Security example scenario
 
-You log into a free Wi-Fi access point at an airport and start surfing the web, visiting your online banking service to check your balance and pay a couple of bills.
+Assume you have logged into a free Wi-Fi access point at an airport and start surfing the web, visiting your online banking service to check your balance and pay a couple of bills.
 Unfortunately, the access point you're using is actually a hacker's laptop, and they're intercepting your original HTTP request and redirecting you to a clone of your bank's site instead of the real thing. Now your private data is exposed to the hacker.
 
-Strict Transport Security resolves this problem; as long as you've accessed your bank's website once using HTTPS, and the bank's website uses Strict Transport Security, your
-browser will know to automatically use only HTTPS, which prevents hackers from performing this sort of man-in-the-middle attack.
+Strict Transport Security resolves this problem; as long as you've accessed your bank's website once using HTTPS, and the bank's website uses Strict Transport Security, your browser will know to automatically use only HTTPS, which prevents hackers from performing this sort of man-in-the-middle attack.
 
-### How the browser handles it
+### How the browser handles Strict Transport Security
 
-The first time your site is accessed using HTTPS and it returns the `Strict-Transport-Security` header, the browser records this information, so that future attempts to load the site using HTTP will automatically use HTTPS instead.
+The first time a site is accessed using HTTPS and it returns the `Strict-Transport-Security` header, the browser records this information, so that future attempts to load the site using HTTP will automatically use HTTPS instead.
 
 When the expiration time specified by the `Strict-Transport-Security` header elapses, the next attempt to load the site via HTTP will proceed as normal instead of automatically using HTTPS.
 
-Whenever the Strict-Transport-Security header is delivered to the browser, it will update the expiration time for that site, so sites can refresh this information and prevent the timeout from expiring.
-Should it be necessary to disable Strict Transport Security, setting the `max-age` to 0 (over an https connection) will immediately expire the `Strict-Transport-Security` header, allowing access via http.
+Whenever the `Strict-Transport-Security` header is delivered to the browser, it will update the expiration time for that site, so sites can refresh this information and prevent the timeout from expiring.
+Should it be necessary to disable Strict Transport Security, setting the `max-age` to `0` (over an HTTPS connection) will immediately expire the `Strict-Transport-Security` header, allowing access via HTTP.
 
-## Preloading Strict Transport Security
+### Preloading Strict Transport Security
 
 Google maintains [an HSTS preload service](https://hstspreload.org/).
 By following the guidelines and successfully submitting your domain, you can ensure that browsers will connect to your domain only via secure connections.
 While the service is hosted by Google, all browsers are using this preload list.
 However, it is not part of the HSTS specification and should not be treated as official.
 
-- Information regarding the HSTS preload list in Chrome: <https://www.chromium.org/hsts/>
+- Information regarding the HSTS preload list in Chrome: https://www.chromium.org/hsts/
 - Consultation of the Firefox HSTS preload list: [nsSTSPreloadList.inc](https://searchfox.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc)
 
 ## Examples
 
+### Using Strict-Transport-Security
+
 All present and future subdomains will be HTTPS for a `max-age` of 1 year.
 This blocks access to pages or subdomains that can only be served over HTTP.
 
@@ -92,7 +93,7 @@ This blocks access to pages or subdomains that can only be served over HTTP.
 Strict-Transport-Security: max-age=31536000; includeSubDomains
 ```
 
-Although a `max-age` of 1 year is acceptable for a domain, two years is the recommended value as explained on <https://hstspreload.org>.
+Although a `max-age` of 1 year is acceptable for a domain, two years is the recommended value as explained on https://hstspreload.org.
 
 In the following example, `max-age` is set to 2 years, and is suffixed with `preload`, which is necessary for inclusion in all major web browsers' HSTS preload lists, like Chromium, Edge, and Firefox.
 
@@ -110,9 +111,9 @@ Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
 
 ## See also
 
-- Blog post: [HTTP Strict Transport Security has landed!](https://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html)
-- Blog post: [HTTP Strict Transport Security (force HTTPS)](https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/)
-- OWASP Article: [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html)
-- Wikipedia: [HTTP Strict Transport Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)
-- [HSTS preload service](https://hstspreload.org/)
 - [Features restricted to secure contexts](/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts)
+- [HTTP Strict Transport Security has landed!](https://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html) on blog.sidstamm.com (2010)
+- [HTTP Strict Transport Security (force HTTPS)](https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/) on hacks.mozilla.org (2010)
+- [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) cheatsheet on owasp.org
+- [HTTP Strict Transport Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) on Wikipedia
+- [HSTS preload service](https://hstspreload.org/)
diff --git a/files/en-us/web/http/headers/supports-loading-mode/index.md b/files/en-us/web/http/headers/supports-loading-mode/index.md
index 4a5997e74076cca..4542398747b9748 100644
--- a/files/en-us/web/http/headers/supports-loading-mode/index.md
+++ b/files/en-us/web/http/headers/supports-loading-mode/index.md
@@ -9,7 +9,7 @@ browser-compat: http.headers.Supports-Loading-Mode
 
 {{HTTPSidebar}}{{securecontext_header}}{{SeeCompatTable}}
 
-The **`Supports-Loading-Mode`** header allows a response to opt-in to being loaded in a novel, higher-risk context that it would otherwise fail to be loaded in.
+The HTTP **`Supports-Loading-Mode`** {{Glossary("response header")}} allows a response to opt-in to being loaded in a novel, higher-risk context that it would otherwise fail to be loaded in.
 
 <table class="properties">
   <tbody>
@@ -19,13 +19,13 @@ The **`Supports-Loading-Mode`** header allows a response to opt-in to being load
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
     <tr>
       <th scope="row">
         {{Glossary("CORS-safelisted response header")}}
       </th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -33,7 +33,7 @@ The **`Supports-Loading-Mode`** header allows a response to opt-in to being load
 ## Syntax
 
 ```http
-Supports-Loading-Mode: <comma-separated list of client hint headers>
+Supports-Loading-Mode: <client-hint-headers>
 ```
 
 ## Directives
diff --git a/files/en-us/web/http/headers/te/index.md b/files/en-us/web/http/headers/te/index.md
index c3c39b816f398a4..ca1ca5eb7bd2854 100644
--- a/files/en-us/web/http/headers/te/index.md
+++ b/files/en-us/web/http/headers/te/index.md
@@ -7,21 +7,13 @@ browser-compat: http.headers.TE
 
 {{HTTPSidebar}}
 
-The **`TE`** request header specifies the transfer encodings
-the user agent is willing to accept. (you could informally call it
-`Accept-Transfer-Encoding`, which would be more intuitive).
+The HTTP **`TE`** {{Glossary("request header")}} specifies the transfer encodings the user agent is willing to accept.
+The transfer encodings are for message compression and chunking of data during transmission.
 
-> [!NOTE]
-> In
-> [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and
-> [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting), the `TE`
-> header field is only accepted if the `trailers` value is set.
+Transfer encodings are applied at the protocol layer, so an application consuming responses receives the body as if no encoding was applied.
 
-See also the {{HTTPHeader("Transfer-Encoding")}} response header for more details on
-transfer encodings. Note that `chunked` is always acceptable for HTTP/1.1
-recipients and you don't have to specify `"chunked"` using the
-`TE` header. However, it is useful for setting if the client is accepting
-trailer fields in a chunked transfer coding using the "trailers" value.
+> [!NOTE]
+> In [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting), the `TE` header field is only accepted if the `trailers` value is set.
 
 <table class="properties">
   <tbody>
@@ -31,7 +23,7 @@ trailer fields in a chunked transfer coding using the "trailers" value.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>yes</td>
+      <td>Yes</td>
     </tr>
   </tbody>
 </table>
@@ -43,29 +35,41 @@ TE: compress
 TE: deflate
 TE: gzip
 TE: trailers
+```
 
-// Multiple directives, weighted with the {{glossary("quality values", "quality value")}} syntax:
+Multiple directives in a comma-separated list with {{glossary("quality values")}} as weights:
+
+```http
 TE: trailers, deflate;q=0.5
 ```
 
 ## Directives
 
 - `compress`
-  - : A format using the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm is
-    accepted as a transfer coding name.
+  - : A format using the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm is accepted as a transfer coding name.
 - `deflate`
-  - : Using the [zlib](https://en.wikipedia.org/wiki/Zlib)
-    structure is accepted as a transfer coding name.
+  - : Using the [zlib](https://en.wikipedia.org/wiki/Zlib) structure is accepted as a transfer coding name.
 - `gzip`
-  - : A format using the [Lempel-Ziv coding](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77)
-    (LZ77), with a 32-bit CRC is accepted as a transfer coding name.
+  - : A format using the [Lempel-Ziv coding](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77), with a 32-bit CRC is accepted as a transfer coding name.
 - `trailers`
-  - : Indicates that the client is willing to accept trailer fields in a chunked transfer
-    coding.
+  - : Indicates that the client will not discard trailer fields in a [chunked transfer coding](/en-US/docs/Web/HTTP/Headers/Transfer-Encoding#chunked).
 - `q`
-  - : When multiple transfer codings are acceptable, the `q` parameter of the
-    [quality value](/en-US/docs/Glossary/Quality_values) syntax can rank
-    codings by preference.
+  - : When multiple transfer codings are acceptable, the `q` parameter ({{glossary("quality values")}}) syntax orders codings by preference.
+
+Note that `chunked` is always supported by HTTP/1.1 recipients, so you don't need to specify it using the `TE` header.
+See the {{HTTPHeader("Transfer-Encoding")}} header for more details.
+
+## Examples
+
+### Using the TE header with quality values
+
+In the following request, the client indicates a preference for `gzip`-encoded responses with `deflate` as a second preference using a `q` value:
+
+```http
+GET /resource HTTP/1.1
+Host: example.com
+TE: gzip; q=1.0, deflate; q=0.8
+```
 
 ## Specifications
 
@@ -78,5 +82,6 @@ TE: trailers, deflate;q=0.5
 ## See also
 
 - {{HTTPHeader("Transfer-Encoding")}}
+- {{HTTPHeader("Content-Encoding")}}
 - {{HTTPHeader("Trailer")}}
 - [Chunked transfer encoding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding)
diff --git a/files/en-us/web/http/headers/timing-allow-origin/index.md b/files/en-us/web/http/headers/timing-allow-origin/index.md
index a021eefcc66a2f2..269f8c0da18b45c 100644
--- a/files/en-us/web/http/headers/timing-allow-origin/index.md
+++ b/files/en-us/web/http/headers/timing-allow-origin/index.md
@@ -7,7 +7,7 @@ browser-compat: http.headers.Timing-Allow-Origin
 
 {{HTTPSidebar}}
 
-The **`Timing-Allow-Origin`** response header specifies origins that are allowed to see values of attributes retrieved via features of the [Resource Timing API](/en-US/docs/Web/API/Performance_API/Resource_timing), which would otherwise be reported as zero due to cross-origin restrictions.
+The HTTP **`Timing-Allow-Origin`** {{Glossary("response header")}} specifies origins that are allowed to see values of attributes retrieved via features of the [Resource Timing API](/en-US/docs/Web/API/Performance_API/Resource_timing), which would otherwise be reported as zero due to cross-origin restrictions.
 
 <table class="properties">
   <tbody>
@@ -17,7 +17,7 @@ The **`Timing-Allow-Origin`** response header specifies origins that are allowed
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -26,18 +26,20 @@ The **`Timing-Allow-Origin`** response header specifies origins that are allowed
 
 ```http
 Timing-Allow-Origin: *
-Timing-Allow-Origin: <origin>[, <origin>]*
+Timing-Allow-Origin: <origin>, …, <originN>
 ```
 
 ## Directives
 
-- `*`
-  - : The server may specify "\*" as a wildcard, thereby allowing any origin to see timing resources.
-- \<origin>
+- `*` (wildcard)
+  - : Any origin may see timing resources.
+- `<origin>`
   - : Specifies a URI that may see the timing resources. You can specify multiple origins, separated by commas.
 
 ## Examples
 
+### Using Timing-Allow-Origin
+
 To allow any resource to see timing resources:
 
 ```http
@@ -61,4 +63,5 @@ Timing-Allow-Origin: https://developer.mozilla.org
 ## See also
 
 - [Resource Timing API](/en-US/docs/Web/API/Performance_API/Resource_timing)
-- {{HTTPHeader("Vary")}}
+- {{HTTPHeader("Server-Timing")}} header
+- {{HTTPHeader("Vary")}} header
diff --git a/files/en-us/web/http/headers/tk/index.md b/files/en-us/web/http/headers/tk/index.md
index 059674c0d9f3b86..bb3c65f61d9e7dd 100644
--- a/files/en-us/web/http/headers/tk/index.md
+++ b/files/en-us/web/http/headers/tk/index.md
@@ -5,15 +5,16 @@ page-type: http-header
 status:
   - deprecated
   - non-standard
+spec-urls: https://www.w3.org/TR/tracking-dnt/
 ---
 
 {{HTTPSidebar}}{{Deprecated_header}}{{non-standard_header}}
 
 > [!NOTE]
 > The DNT (Do Not Track) specification has been discontinued. See {{domxref("Navigator.doNotTrack")}} for more information.
+> An alternative is [Global Privacy Control](https://globalprivacycontrol.org/), which is communicated to servers using the {{HTTPHeader("Sec-GPC")}} header, and accessible to clients from {{domxref("navigator.globalPrivacyControl")}}.
 
-The **`Tk`** response header indicates the tracking status that
-applied to the corresponding request.
+The HTTP **`Tk`** {{Glossary("response header")}} indicates the tracking status that applied to the corresponding request.
 
 <table class="properties">
   <tbody>
@@ -23,7 +24,7 @@ applied to the corresponding request.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -44,31 +45,31 @@ Tk: U  (updated)
 
 ### Directives
 
-- !
+- `!`
   - : Under construction. The origin server is currently testing its communication of
     tracking status.
-- ?
+- `?`
   - : Dynamic. The origin server needs more information to determine tracking status.
-- G
+- `G`
   - : Gateway or multiple parties. The server is acting as a gateway to an exchange
     involving multiple parties.
-- N
+- `N`
   - : Not tracking.
-- T
+- `T`
   - : Tracking.
-- C
+- `C`
   - : Tracking with consent. The origin server believes it has received prior consent for
     tracking this user, user agent, or device.
-- P
+- `P`
   - : Potential consent. The origin server does not know, in real-time, whether it has
     received prior consent for tracking this user, user agent, or device, but promises not
     to use or share any `DNT:1` data until such consent has been determined,
     and further promises to delete or permanently de-identify within 48 hours any
     `DNT:1` data received for which such consent has not been received.
-- D
+- `D`
   - : Disregarding DNT. The origin server is unable or unwilling to respect a tracking
     preference received from the requesting user agent.
-- U
+- `U`
   - : Updated. The request resulted in a potential change to the tracking status
     applicable to this user, user agent, or device.
 
@@ -82,9 +83,14 @@ Tk: N
 
 ## Specifications
 
-Part of the discontinued [Tracking Preference Expression (DNT)](https://www.w3.org/TR/tracking-dnt/#response-header-field) specification.
+{{specifications}}
 
 ## See also
 
 - {{HTTPHeader("DNT")}} header
 - {{domxref("Navigator.doNotTrack")}}
+- [Do Not Track on Wikipedia](https://en.wikipedia.org/wiki/Do_Not_Track)
+- [What Does the "Track" in "Do Not Track" Mean? – EFF](https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean)
+- [DNT on Electronic Frontier Foundation](https://www.eff.org/issues/do-not-track)
+- [GPC - Global Privacy Control](https://globalprivacycontrol.org/)
+  - [Enabling GPC in Firefox](https://support.mozilla.org/en-US/kb/global-privacy-control?as=u&utm_source=inproduct)
diff --git a/files/en-us/web/http/headers/trailer/index.md b/files/en-us/web/http/headers/trailer/index.md
index 43fb68b52665529..aa3761ecbc514c8 100644
--- a/files/en-us/web/http/headers/trailer/index.md
+++ b/files/en-us/web/http/headers/trailer/index.md
@@ -7,14 +7,15 @@ browser-compat: http.headers.Trailer
 
 {{HTTPSidebar}}
 
-The **Trailer** response header allows the sender to include additional
-fields at the end of chunked messages in order to supply metadata that might be
-dynamically generated while the message body is sent, such as a message integrity check,
-digital signature, or post-processing status.
+The HTTP **Trailer** {{glossary("request header", "request")}} and {{glossary("response header")}} allows the sender to include additional fields at the end of chunked messages in order to supply metadata that might be dynamically generated while the message body is sent.
 
 > [!NOTE]
-> The {{HTTPHeader("TE")}} request header needs to be set to "trailers" to allow
-> trailer fields.
+> The {{HTTPHeader("TE")}} request header needs to be set to `trailers` to allow trailer fields.
+
+> [!WARNING]
+> Developers cannot access HTTP trailers via the Fetch API or XHR.
+> Additionally, browsers ignore HTTP trailers, with the exception of {{HTTPHeader("Server-Timing")}}.
+> See [Browser compatibility](#browser_compatibility) for more information.
 
 <table class="properties">
   <tbody>
@@ -28,7 +29,7 @@ digital signature, or post-processing status.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>yes</td>
+      <td>Yes</td>
     </tr>
   </tbody>
 </table>
@@ -44,41 +45,29 @@ Trailer: header-names
 - `header-names`
 
   - : HTTP header fields which will be present in the trailer part of chunked messages.
-    These header fields are **disallowed**:
-
-    - message framing headers (e.g., {{HTTPHeader("Transfer-Encoding")}} and
-      {{HTTPHeader("Content-Length")}}),
-    - routing headers (e.g., {{HTTPHeader("Host")}}),
-    - request modifiers (e.g., controls and conditionals, like
-      {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Max-Forwards")}}, or
-      {{HTTPHeader("TE")}}),
-    - authentication headers (e.g., {{HTTPHeader("Authorization")}} or
-      {{HTTPHeader("Set-Cookie")}}),
-    - or {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Type")}},
-      {{HTTPHeader("Content-Range")}}, and `Trailer` itself.
+    The following header names are **disallowed**:
+
+    - {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Content-Range")}}, and `Trailer`
+    - Authentication headers (e.g., {{HTTPHeader("Authorization")}} or {{HTTPHeader("Set-Cookie")}})
+    - Message framing headers (e.g., {{HTTPHeader("Transfer-Encoding")}} and {{HTTPHeader("Content-Length")}})
+    - Routing headers (e.g., {{HTTPHeader("Host")}})
+    - Request modifiers (e.g., controls and conditionals, like {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Max-Forwards")}}, or {{HTTPHeader("TE")}})
 
 ## Examples
 
-### Chunked transfer encoding using a trailing header
+### Server-Timing as HTTP trailer
 
-In this example, the {{HTTPHeader("Expires")}} header is used at the end of the chunked
-message and serves as a trailing header.
+Some browsers support showing server timing data in developer tools when the {{HTTPHeader("Server-Timing")}} header is sent as a trailer.
+In the following response, the `Trailer` header is used to indicate that a `Server-Timing` header will follow the response body.
+A metric `custom-metric` with a duration of `123.4` milliseconds is sent:
 
 ```http
 HTTP/1.1 200 OK
-Content-Type: text/plain
 Transfer-Encoding: chunked
-Trailer: Expires
-
-7\r\n
-Mozilla\r\n
-9\r\n
-Developer\r\n
-7\r\n
-Network\r\n
-0\r\n
-Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
-\r\n
+Trailer: Server-Timing
+
+--- response body ---
+Server-Timing: custom-metric;dur=123.4
 ```
 
 ## Specifications
@@ -91,6 +80,7 @@ Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
 
 ## See also
 
+- {{HTTPHeader("Server-Timing")}}
 - {{HTTPHeader("Transfer-Encoding")}}
 - {{HTTPHeader("TE")}}
 - [Chunked transfer encoding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding)
diff --git a/files/en-us/web/http/headers/transfer-encoding/index.md b/files/en-us/web/http/headers/transfer-encoding/index.md
index 575cb5618c0d435..a36a6c9c864c02c 100644
--- a/files/en-us/web/http/headers/transfer-encoding/index.md
+++ b/files/en-us/web/http/headers/transfer-encoding/index.md
@@ -7,12 +7,7 @@ browser-compat: http.headers.Transfer-Encoding
 
 {{HTTPSidebar}}
 
-The **`Transfer-Encoding`** header specifies the form of encoding used to transfer messages between nodes on the network.
-
-> [!WARNING]
-> HTTP/2 disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: `"trailers"`.
-> HTTP/2 and later provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header.
-> Usage of the header in HTTP/2 may likely result in a specific `protocol error` as HTTP/2 Protocol prohibits the use.
+The HTTP **`Transfer-Encoding`** {{glossary("request header", "request")}} and {{glossary("response header")}} specifies the form of encoding used to transfer messages between nodes on the network.
 
 `Transfer-Encoding` is a [hop-by-hop header](/en-US/docs/Web/HTTP/Headers#hop-by-hop_headers), that is applied to a message between two nodes, not to a resource itself.
 Each segment of a multi-node connection can use different `Transfer-Encoding` values.
@@ -20,6 +15,11 @@ If you want to compress data over the whole connection, use the end-to-end {{HTT
 
 When present on a response to a {{HTTPMethod("HEAD")}} request that has no body, it indicates the value that would have applied to the corresponding {{HTTPMethod("GET")}} message.
 
+> [!WARNING]
+> HTTP/2 disallows all uses of the `Transfer-Encoding` header other than the HTTP/2 specific value `"trailers"`.
+> HTTP/2 and later provide more efficient mechanisms for data streaming than chunked transfer.
+> Usage of the header in HTTP/2 may likely result in a specific `protocol error`.
+
 <table class="properties">
   <tbody>
     <tr>
@@ -30,7 +30,7 @@ When present on a response to a {{HTTPMethod("HEAD")}} request that has no body,
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>yes</td>
+      <td>Yes</td>
     </tr>
   </tbody>
 </table>
@@ -50,9 +50,10 @@ Transfer-Encoding: gzip, chunked
 ## Directives
 
 - `chunked`
-  - : Data is sent in a series of chunks. The {{HTTPHeader("Content-Length")}} header is omitted in this case and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format, followed by `\r\n` and then the chunk itself, followed by another `\r\n`.
-    The terminating chunk is a regular chunk, with the exception that its length is zero.
-    It is followed by the trailer, which consists of a (possibly empty) sequence of header fields.
+  - : Data is sent in a series of chunks.
+    Content can be sent in streams of unknown size to be transferred as a sequence of length-delimited buffers, so the sender can keep a connection open, and let the recipient know when it has received the entire message.
+    The {{HTTPHeader("Content-Length")}} header must be omitted, and at the beginning of each chunk, a string of hex digits indicate the size of the chunk-data in octets, followed by `\r\n` and then the chunk itself, followed by another `\r\n`.
+    The terminating chunk is a zero-length chunk.
 - `compress`
   - : A format using the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm.
     The value name was taken from the UNIX _compress_ program, which implemented this algorithm.
@@ -66,7 +67,7 @@ Transfer-Encoding: gzip, chunked
 
 ## Examples
 
-### Chunked encoding
+### Response with chunked encoding
 
 Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed.
 For example, when generating a large HTML table resulting from a database query or when transmitting large images.
diff --git a/files/en-us/web/http/headers/upgrade-insecure-requests/index.md b/files/en-us/web/http/headers/upgrade-insecure-requests/index.md
index 5ccafba3c7203a3..57286974b2140aa 100644
--- a/files/en-us/web/http/headers/upgrade-insecure-requests/index.md
+++ b/files/en-us/web/http/headers/upgrade-insecure-requests/index.md
@@ -7,7 +7,7 @@ browser-compat: http.headers.Upgrade-Insecure-Requests
 
 {{HTTPSidebar}}
 
-The HTTP **`Upgrade-Insecure-Requests`** request header sends a signal to the server expressing the client's preference for an encrypted and authenticated response, and that it can successfully handle the {{CSP("upgrade-insecure-requests")}} [CSP](/en-US/docs/Web/HTTP/CSP) directive.
+The HTTP **`Upgrade-Insecure-Requests`** {{Glossary("request header")}} sends a signal to the server indicating the client's preference for an encrypted and authenticated response, and that the client can successfully handle the {{CSP("upgrade-insecure-requests")}} [CSP](/en-US/docs/Web/HTTP/CSP) directive.
 
 <table class="properties">
   <tbody>
@@ -17,7 +17,7 @@ The HTTP **`Upgrade-Insecure-Requests`** request header sends a signal to the se
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -25,11 +25,18 @@ The HTTP **`Upgrade-Insecure-Requests`** request header sends a signal to the se
 ## Syntax
 
 ```http
-Upgrade-Insecure-Requests: 1
+Upgrade-Insecure-Requests: <boolean>
 ```
 
+## Directives
+
+- `<boolean>`
+  - : `1` indicates 'true' and is the only valid value for this field.
+
 ## Examples
 
+### Using Upgrade-Insecure-Requests
+
 A client's request signals to the server that it supports the upgrade mechanisms of {{CSP("upgrade-insecure-requests")}}:
 
 ```http
@@ -57,3 +64,4 @@ Vary: Upgrade-Insecure-Requests
 
 - {{HTTPHeader("Content-Security-Policy")}}
 - CSP {{CSP("upgrade-insecure-requests")}} directive
+- [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header
diff --git a/files/en-us/web/http/headers/upgrade/index.md b/files/en-us/web/http/headers/upgrade/index.md
index 995044d0b993898..8aea9507ba4f6b1 100644
--- a/files/en-us/web/http/headers/upgrade/index.md
+++ b/files/en-us/web/http/headers/upgrade/index.md
@@ -7,10 +7,11 @@ browser-compat: http.headers.Upgrade
 
 {{HTTPSidebar}}
 
-The HTTP 1.1 (only) `Upgrade` header can be used to upgrade an already established client/server connection to a different protocol (over the same transport protocol). For example, it can be used by a client to upgrade a connection from HTTP 1.1 to HTTP 2.0, or an HTTP or HTTPS connection into a WebSocket.
+The HTTP `Upgrade` {{glossary("request header", "request")}} and {{glossary("response header")}} can be used to upgrade an already-established client/server connection to a different protocol (over the same transport protocol).
+For example, it can be used by a client to upgrade a connection from HTTP/1.1 to HTTP/2, or an HTTP(S) connection to a WebSocket connection.
 
 > [!WARNING]
-> HTTP/2 explicitly disallows the use of this mechanism/header; it is specific to HTTP/1.1.
+> HTTP/2 explicitly disallows the use of this mechanism and header; it is specific to HTTP/1.1.
 
 <table class="properties">
   <tbody>
@@ -23,16 +24,31 @@ The HTTP 1.1 (only) `Upgrade` header can be used to upgrade an already establish
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>yes</td>
+      <td>Yes</td>
     </tr>
   </tbody>
 </table>
 
-## Overview
+## Syntax
 
-The `Upgrade` header field may be used by clients to invite a server to switch to one (or more) of the listed protocols, in descending preference order.
+A comma-separated list of one or more protocols:
+
+```http
+Upgrade: <protocol>[/<protocol_version>]
+Upgrade: <protocol>[/<protocol_version>], …, <protocolN>[/<protocol_versionN>]
+```
+
+## Directives
 
-For example, the client might send a `GET` request as shown, listing the preferred protocols to switch to (in this case "example/1" and "foo/2"):
+- `<protocol>`
+  - : Protocols are listed, comma-separated, in order of descending preference.
+- `<protocol_version>` {{optional_inline}}
+  - : An optional protocol version may be provided prefixed with a `/` forward slash.
+
+## Description
+
+The `Upgrade` header field may be used by clients to invite a server to switch to one (or more) of the listed protocols, in descending preference order.
+For example, the client might send a `GET` request as shown, listing the preferred protocols to switch to (in this case `example/1` and `foo/2`):
 
 ```http
 GET /index.html HTTP/1.1
@@ -41,11 +57,11 @@ Connection: upgrade
 Upgrade: example/1, foo/2
 ```
 
-> **Note:** `Connection: upgrade` must be set whenever `Upgrade` is sent.
+> [!NOTE]
+> The {{HTTPHeader("Connection")}} header with type `upgrade` must _always_ be sent with the `Upgrade` header.
 
-The server can choose to ignore the request, for any reason, in which case it should just respond as though the `Upgrade` header had not been sent (for example, with a {{HTTPStatus(200, "200 OK")}}).
-
-If the server decides to upgrade the connection, it must:
+The server can ignore the request, for any reason, in which case it should respond as though the `Upgrade` header had not been sent (for example, with a {{HTTPStatus(200, "200 OK")}}).
+If the server will upgrade the connection, it must:
 
 1. Send back a {{HTTPStatus(101, "101 Switching Protocols")}} response status with an `Upgrade` header that specifies the protocol(s) being switched to. For example:
 
@@ -61,34 +77,21 @@ A server may also send the header as part of a {{HTTPStatus("426")}} `Upgrade Re
 
 More detail and examples are provided in the topic [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism).
 
-## Syntax
-
-```http
-Connection: upgrade
-Upgrade: protocol_name[/protocol_version]
-```
+## Examples
 
-Notes:
+### Upgrade header with multiple protocols
 
-- The {{HTTPHeader("Connection")}} header with type `upgrade` must _always_ be sent with the `Upgrade` header (as shown above).
-- Protocols are listed, comma-separated, in order of descending preference. Protocol version is optional. For example:
+The following request lists multiple protocols in descending preference:
 
 ```http
 Connection: upgrade
-Upgrade: a_protocol/1, example, another_protocol/2.2
+Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
 ```
 
-## Directives
-
-- any comma-separated list protocol names (each with optional protocol version)
-  - : One or more protocol names with optional version ("/" separated). The protocols are listed in order of descending preference.
+### Upgrading to WebSocket
 
-## Examples
-
-```http
-Connection: upgrade
-Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
-```
+This is a common combination of headers to use to begin upgrading a HTTP connection to WebSockets.
+See [Upgrading to a WebSocket connection](/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism#upgrading_to_a_websocket_connection) for more information.
 
 ```http
 Connection: Upgrade
@@ -106,6 +109,6 @@ Upgrade: websocket
 ## See also
 
 - [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism)
-- {{HTTPStatus("101")}} `Switching Protocol`
-- {{HTTPStatus("426")}} `Upgrade Required`
+- {{HTTPStatus(101, "101 Switching Protocols")}}
+- {{HTTPStatus(426, "426 Upgrade Required")}}
 - {{HTTPHeader("Connection")}}
diff --git a/files/en-us/web/http/headers/user-agent/index.md b/files/en-us/web/http/headers/user-agent/index.md
index e84d5e7e49316e2..6bb931681725918 100644
--- a/files/en-us/web/http/headers/user-agent/index.md
+++ b/files/en-us/web/http/headers/user-agent/index.md
@@ -7,10 +7,10 @@ browser-compat: http.headers.User-Agent
 
 {{HTTPSidebar}}
 
-The **User-Agent** {{Glossary("request header")}} is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting {{Glossary("user agent")}}.
+The HTTP **User-Agent** {{Glossary("request header")}} is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting {{Glossary("user agent")}}.
 
 > [!WARNING]
-> Please read [Browser detection using the user agent](/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent) for why serving different Web pages or services to different browsers is usually a bad idea.
+> See [Browser detection using the user agent](/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent) for reasons why serving different content to different browsers is usually a bad idea.
 
 <table class="properties">
   <tbody>
@@ -20,7 +20,7 @@ The **User-Agent** {{Glossary("request header")}} is a characteristic string tha
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -39,11 +39,11 @@ User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <
 
 ### Directives
 
-- \<product>
+- `<product>`
   - : A product identifier — its name or development codename.
-- \<product-version>
+- `<product-version>`
   - : Version number of the product.
-- \<comment>
+- `<comment>`
   - : Zero or more comments containing more details. For example, sub-product information.
 
 ## Firefox UA string
diff --git a/files/en-us/web/http/headers/vary/index.md b/files/en-us/web/http/headers/vary/index.md
index be48313206a6b2d..e7a3217745ae0cd 100644
--- a/files/en-us/web/http/headers/vary/index.md
+++ b/files/en-us/web/http/headers/vary/index.md
@@ -7,7 +7,9 @@ browser-compat: http.headers.Vary
 
 {{HTTPSidebar}}
 
-The **`Vary`** HTTP response header describes the parts of the request message aside from the method and URL that influenced the content of the response it occurs in. Most often, this is used to create a cache key when [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) is in use.
+The HTTP **`Vary`** {{Glossary("response header")}} describes the parts of the request message (aside from the method and URL) that influenced the content of the response it occurs in.
+Including a `Vary` header ensures that responses are separately cached based on the headers listed in the `Vary` field.
+Most often, this is used to create a cache key when [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) is in use.
 
 The same `Vary` header value should be used on all responses for a given URL, including {{HTTPStatus("304")}} `Not Modified` responses and the "default" response.
 
@@ -19,24 +21,26 @@ The same `Vary` header value should be used on all responses for a given URL, in
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
 ## Syntax
 
+Either `*` as a wildcard, or one or more header names in a comma-separated list:
+
 ```http
 Vary: *
-Vary: <header-name>, <header-name>, ...
+Vary: <header-name>, …, <header-nameN>
 ```
 
 ## Directives
 
-- \*
-  - : Indicates that factors other than request headers influenced the generation of this response. Implies that the response is uncacheable.
-- \<header-name>
-  - : A comma-separated list of request header names that could have influenced the generation of this response.
+- `*` (wildcard)
+  - : Factors other than request headers influenced the generation of this response. Implies that the response is uncacheable.
+- `<header-name>`
+  - : A request header name that could have influenced the generation of this response.
 
 ## Specifications
 
@@ -46,12 +50,9 @@ Vary: <header-name>, <header-name>, ...
 
 {{Compat}}
 
-### Compatibility notes
-
-- [Vary with care – Vary header problems in IE6-9](https://learn.microsoft.com/en-us/archive/blogs/ieinternals/vary-with-care)
-
 ## See also
 
-- [Understanding The Vary Header - Smashing Magazine](https://www.smashingmagazine.com/2017/11/understanding-vary-header/)
-- [Best Practices for Using the Vary Header – fastly.com](https://www.fastly.com/blog/best-practices-using-vary-header)
 - [Content negotiation](/en-US/docs/Web/HTTP/Content_negotiation)
+- [HTTP caching: Vary](/en-US/docs/Web/HTTP/Caching#vary)
+- [Understanding The Vary Header](https://www.smashingmagazine.com/2017/11/understanding-vary-header/) on smashingmagazine.com (2017)
+- [Best Practices for Using the Vary Header](https://www.fastly.com/blog/best-practices-using-vary-header) on fastly.com
diff --git a/files/en-us/web/http/headers/via/index.md b/files/en-us/web/http/headers/via/index.md
index c534686aaf4de49..548d407db295eb2 100644
--- a/files/en-us/web/http/headers/via/index.md
+++ b/files/en-us/web/http/headers/via/index.md
@@ -7,10 +7,8 @@ browser-compat: http.headers.Via
 
 {{HTTPSidebar}}
 
-The **`Via`** general header is added by proxies, both forward
-and reverse, and can appear in the request or response headers. It
-is used for tracking message forwards, avoiding request loops, and identifying the
-protocol capabilities of senders along the request/response chain.
+The **`Via`** {{glossary("request header", "request")}} and {{glossary("response header")}} is added by {{Glossary("Proxy_server", "proxies")}}, both forward and reverse.
+It is used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain.
 
 <table class="properties">
   <tbody>
@@ -23,7 +21,7 @@ protocol capabilities of senders along the request/response chain.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>yes</td>
+      <td>Yes</td>
     </tr>
   </tbody>
 </table>
@@ -31,20 +29,22 @@ protocol capabilities of senders along the request/response chain.
 ## Syntax
 
 ```http
-Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
-Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>
+Via: [<protocol-name>/]<protocol-version> <host>[:<port>]
+Via: [<protocol-name>/]<protocol-version> <pseudonym>
 ```
 
 ## Directives
 
-- \<protocol-name>
-  - : Optional. The name of the protocol used, such as "HTTP".
-- \<protocol-version>
+- `<protocol-name>` {{optional_inline}}
+  - : The name of the protocol used, such as "HTTP".
+- `<protocol-version>`
   - : The version of the protocol used, such as "1.1".
-- \<host> and \<port>
-  - : Public proxy URL and port.
-- \<pseudonym>
+- `<host>`
+  - : Public proxy URL and optional `<port>`.
+    If a host is not provided, then a `<pseudonym>` must be used.
+- `<pseudonym>`
   - : Name/alias of an internal proxy.
+    If a pseudonym is not provided, then a `<host>` must be used.
 
 ## Examples
 
diff --git a/files/en-us/web/http/headers/viewport-width/index.md b/files/en-us/web/http/headers/viewport-width/index.md
index db41794ff3bd39e..5248070a26916d6 100644
--- a/files/en-us/web/http/headers/viewport-width/index.md
+++ b/files/en-us/web/http/headers/viewport-width/index.md
@@ -10,7 +10,18 @@ browser-compat: http.headers.Viewport-Width
 
 {{HTTPSidebar}}{{Deprecated_Header}}{{SecureContext_header}}{{Non-standard_Header}}
 
-The **`Viewport-Width`** [device client hint](/en-US/docs/Web/HTTP/Client_hints) request header provides the client's layout viewport width in {{Glossary("CSS pixel","CSS pixels")}}. The value is rounded up to the smallest following integer (i.e. ceiling value).
+> [!WARNING]
+> The `Viewport-Width` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07).
+> The proposed replacement is [`Sec-CH-Viewport-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-width) (Responsive Image Client Hints).
+
+The HTTP **`Viewport-Width`** {{Glossary("request header")}} is a [device client hint](/en-US/docs/Web/HTTP/Client_hints) which provides the client's layout viewport width in {{Glossary("CSS pixel", "CSS pixels")}}.
+The value is rounded up to the smallest following integer (i.e., ceiling value).
+
+The hint can be used with other screen-specific hints to deliver images optimized for a specific screen size, or to omit resources that are not needed for a particular screen width.
+If the `Viewport-Width` header appears more than once in a message the last occurrence is used.
+
+A server has to opt-in to receive the `Viewport-Width` header from the client, by sending the {{HTTPHeader("Accept-CH")}} response header.
+Servers that opt-in will typically also specify it in the {{HTTPHeader("Vary")}} header which informs caches that the server may send different responses based on the header value in a request.
 
 <table class="properties">
   <tbody>
@@ -23,22 +34,11 @@ The **`Viewport-Width`** [device client hint](/en-US/docs/Web/HTTP/Client_hints)
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
-The hint can be used with other screen-specific hints to deliver images optimized for a specific screen size, or to omit resources that are not needed for a particular screen width.
-
-If the `Viewport-Width` header appears more than once in a message the last occurrence is used.
-
-> [!NOTE]
->
-> - Client Hints are accessible only on secure origins (via TLS).
-> - A server has to opt in to receive the `Viewport-Width` header from the client, by sending the {{HTTPHeader("Accept-CH")}} response header.
-> - Servers that opt in to the `Viewport-Width` client hint will typically also specify it in the {{HTTPHeader("Vary")}} header. This informs caches that the server may send different responses based on the header value in a request.
-> - `Viewport-Width` was removed from the original client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-Viewport-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-width) (Responsive Image Client Hints).
-
 ## Syntax
 
 ```http
@@ -47,18 +47,20 @@ Viewport-Width: <number>
 
 ## Directives
 
-- \<number>
+- `<number>`
   - : The width of the user's viewport in {{Glossary("CSS pixel","CSS pixels")}}, rounded up to the nearest integer.
 
 ## Examples
 
-A server must first opt in to receive the `Viewport-Width` header by sending the response header {{HTTPHeader("Accept-CH")}} containing the directive `Viewport-Width`.
+### Using Viewport-Width
+
+A server must first opt-in to receive the `Viewport-Width` header by sending the response header {{HTTPHeader("Accept-CH")}} containing the directive `Viewport-Width`.
 
 ```http
 Accept-CH: Viewport-Width
 ```
 
-Then on subsequent requests the client might send `Viewport-Width` header back:
+In subsequent requests, the client might send `Viewport-Width` header:
 
 ```http
 Viewport-Width: 320
@@ -71,12 +73,6 @@ Viewport-Width: 320
 ## See also
 
 - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)
-- Device client hints
-
-  - {{HTTPHeader("Content-DPR")}}
-  - {{HTTPHeader("Device-Memory")}}
-  - {{HTTPHeader("DPR")}}
-  - {{HTTPHeader("Width")}}
-
+- {{HTTPHeader("Content-DPR")}}, {{HTTPHeader("Device-Memory")}}, {{HTTPHeader("DPR")}}, {{HTTPHeader("Width")}} device client hints
 - {{HTTPHeader("Accept-CH")}}
-- [HTTP Caching > Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}}
+- [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header
diff --git a/files/en-us/web/http/headers/want-content-digest/index.md b/files/en-us/web/http/headers/want-content-digest/index.md
index 71b19e0748e9a9d..526a3781b6115d6 100644
--- a/files/en-us/web/http/headers/want-content-digest/index.md
+++ b/files/en-us/web/http/headers/want-content-digest/index.md
@@ -2,12 +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 **`Want-Content-Digest`** request or response header states the wish for 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>
@@ -17,27 +22,46 @@ The **`Want-Content-Digest`** request or response header states the wish for a {
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
 ## Syntax
 
-`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).
+A comma-separated list of one or more hashing algorithms:
 
-> [!NOTE]
-> In contrast to earlier drafts of the specifications, the weighting is _not_ declared via [q-values](/en-US/docs/Glossary/Quality_values).
+```http
+Want-Content-Digest: <algorithm>=<preference>
+Want-Content-Digest: <algorithm>=<preference>, …, <algorithmN>=<preferenceN>
+```
 
 ## Directives
 
-For permissible digest algorithms see {{HTTPHeader("Repr-Digest")}}.
+- `<algorithm>`
+  - : The requested algorithm 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).
 
 ## Examples
 
+### Using Want-Content-Digest in requests
+
+The following message asks the recipient to send a `Content-Digest` header using SHA-512 algorithm:
+
+```http
+Want-Content-Digest: sha-512=9
+```
+
+### Want-Content-Digest with multiple values
+
+The following header contains three algorithms, and indicates that SHA-256 is the preferred digest algorithm that the recipient should use, followed by SHA-512, and MD5:
+
 ```http
-Want-Content-Digest: md5=1, sha-512=0, sha-256=4
-Want-Content-Digest: md5=0
+Want-Content-Digest: md5=1, sha-512=2, sha-256=3
 ```
 
 ## Specifications
@@ -51,4 +75,5 @@ 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")}}
+- {{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)
diff --git a/files/en-us/web/http/headers/want-repr-digest/index.md b/files/en-us/web/http/headers/want-repr-digest/index.md
index 241abcebb0a643f..2e062e80affa2bd 100644
--- a/files/en-us/web/http/headers/want-repr-digest/index.md
+++ b/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 **`Want-Repr-Digest`** request or response header states the wish for 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>
@@ -17,21 +22,29 @@ The **`Want-Repr-Digest`** request or response header states the wish for a {{HT
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
 ## Syntax
 
-`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).
+A comma-separated list of one or more hashing algorithms:
 
-> [!NOTE]
-> In contrast to earlier drafts of the specifications, the weighting is _not_ declared via [q-values](/en-US/docs/Glossary/Quality_values).
+```http
+Want-Repr-Digest: <algorithm>=<preference>
+Want-Repr-Digest: <algorithm>=<preference>, …, <algorithmN>=<preferenceN>
+```
 
 ## Directives
 
-For permissible digest algorithms see {{HTTPHeader("Repr-Digest")}}.
+- `<algorithm>`
+  - : The requested algorithm 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).
 
 ## Examples
 
@@ -51,4 +64,5 @@ 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")}}
+- {{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)
diff --git a/files/en-us/web/http/headers/warning/index.md b/files/en-us/web/http/headers/warning/index.md
index be3a0a02d862936..6ddc9b9006f6e8a 100644
--- a/files/en-us/web/http/headers/warning/index.md
+++ b/files/en-us/web/http/headers/warning/index.md
@@ -13,7 +13,7 @@ browser-compat: http.headers.Warning
 > The header was deprecated because it is not widely generated or surfaced to users (see [RFC9111](https://www.rfc-editor.org/rfc/rfc9111#field.warning)).
 > Some of the information can be inferred from other headers such as {{httpheader("Age")}}.
 
-The **`Warning`** HTTP header contains information about possible problems with the status of the message.
+The HTTP **`Warning`** {{glossary("request header", "request")}} and {{glossary("response header")}} contains information about possible problems with the status of the message.
 More than one `Warning` header may appear in a response.
 
 `Warning` header fields can, in general, be applied to any message.
@@ -30,7 +30,7 @@ However, some warn-codes are specific to caches and can only be applied to respo
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -43,19 +43,19 @@ Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]
 
 ## Directives
 
-- \<warn-code>
+- `<warn-code>`
 
   - : A three-digit warning number. The first digit indicates whether the `Warning` is required to be deleted from a stored response after validation.
 
     - `1xx` warn-codes describe the freshness or validation status of the response and will be deleted by a cache after successful validation.
     - `2xx` warn-codes describe some aspect of the representation that is not rectified by a validation and will not be deleted by a cache after validation unless a full response is sent.
 
-- \<warn-agent>
+- `<warn-agent>`
   - : The name or pseudonym of the server or software adding the `Warning` header (might be "-" when the agent is unknown).
-- \<warn-text>
+- `<warn-text>`
   - : An advisory text describing the error.
-- \<warn-date>
-  - : A date. This is optional. If more than one `Warning` header is sent, include a date that matches the {{HTTPHeader("Date")}} header.
+- `<warn-date>` {{optional_inline}}
+  - : A date. If more than one `Warning` header is sent, include a date that matches the {{HTTPHeader("Date")}} header.
 
 ## Warning codes
 
diff --git a/files/en-us/web/http/headers/width/index.md b/files/en-us/web/http/headers/width/index.md
index 08c3b5f6256a74f..98f93b155cbc034 100644
--- a/files/en-us/web/http/headers/width/index.md
+++ b/files/en-us/web/http/headers/width/index.md
@@ -10,7 +10,15 @@ browser-compat: http.headers.Width
 
 {{HTTPSidebar}}{{Deprecated_Header}}{{SecureContext_header}}{{Non-standard_Header}}
 
-The **`Width`** [device client hint](/en-US/docs/Web/HTTP/Client_hints#device_client_hints) request header field indicates the desired resource width in physical pixels — the intrinsic size of an image. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).
+> [!WARNING]
+> The `Width` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-width) (Responsive Image Client Hints).
+
+The HTTP **`Width`** {{Glossary("request header")}} is a [device client hint](/en-US/docs/Web/HTTP/Client_hints#device_client_hints) which indicates the desired resource width in physical pixels — the intrinsic size of an image. The provided pixel value is a number rounded to the smallest following integer (i.e., ceiling value).
+
+The hint allows the client to request a resource that is optimal for both the screen and the layout: taking into account both the density-corrected width of the screen and the image's extrinsic size within the layout.
+
+If the desired resource width is not known at the time of the request or the resource does not have a display width, the `Width` header field can be omitted.
+If the `Width` header appears more than once in a message the last occurrence is used.
 
 <table class="properties">
   <tbody>
@@ -23,24 +31,11 @@ The **`Width`** [device client hint](/en-US/docs/Web/HTTP/Client_hints#device_cl
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
-The hint is particularly useful because it allows the client to request a resource that is optimal for both the screen and the layout: taking into account both the density-corrected width of the screen and the image's extrinsic size within the layout.
-
-If the desired resource width is not known at the time of the request or the resource does not have a display width, the `Width` header field can be omitted.
-
-If the `Width` header appears more than once in a message the last occurrence is used.
-
-> [!NOTE]
->
-> - Client Hints are accessible only on secure origins (via TLS).
-> - A server has to opt in to receive the `Width` header from the client, by sending the {{HTTPHeader("Accept-CH")}} response header.
-> - Servers that opt in to the `Width` client hint will typically also specify it in the {{HTTPHeader("Vary")}} header. This informs caches that the server may send different responses based on the header value in a request.
-> - `Width` was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-width) (Responsive Image Client Hints).
-
 ## Syntax
 
 ```http
@@ -49,7 +44,7 @@ Width: <number>
 
 ## Directives
 
-- \<number>
+- `<number>`
   - : The width of the resource in physical pixels, rounded up to the nearest integer.
 
 ## Examples
@@ -72,13 +67,7 @@ Width: 1920
 
 ## See also
 
-- [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)
-- Device client hints
-
-  - {{HTTPHeader("Content-DPR")}}
-  - {{HTTPHeader("Device-Memory")}}
-  - {{HTTPHeader("DPR")}}
-  - {{HTTPHeader("Viewport-Width")}}
-
+- {{HTTPHeader("Content-DPR")}}, {{HTTPHeader("Device-Memory")}}, {{HTTPHeader("DPR")}}, {{HTTPHeader("Viewport-Width")}} device client hints
 - {{HTTPHeader("Accept-CH")}}
-- [HTTP Caching > Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}}
+- [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header
+- [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)
diff --git a/files/en-us/web/http/headers/www-authenticate/index.md b/files/en-us/web/http/headers/www-authenticate/index.md
index a6444cd2d67652c..aeb27cfbf0c1347 100644
--- a/files/en-us/web/http/headers/www-authenticate/index.md
+++ b/files/en-us/web/http/headers/www-authenticate/index.md
@@ -7,20 +7,19 @@ browser-compat: http.headers.WWW-Authenticate
 
 {{HTTPSidebar}}
 
-The HTTP **`WWW-Authenticate`** response header defines the [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) methods ("challenges") that might be used to gain access to a specific resource.
+The HTTP **`WWW-Authenticate`** {{Glossary("response header")}} advertises the [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) methods (or {{Glossary("challenge", "challenges")}}) that might be used to gain access to a specific resource.
 
-> [!NOTE]
-> This header is part of the [General HTTP authentication framework](/en-US/docs/Web/HTTP/Authentication#the_general_http_authentication_framework), which can be used with a number of [authentication schemes](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).
-> Each "challenge" lists a scheme supported by the server and additional parameters that are defined for that scheme type.
+This header is part of the [General HTTP authentication framework](/en-US/docs/Web/HTTP/Authentication#the_general_http_authentication_framework), which can be used with a number of [authentication schemes](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).
+Each challenge identifies a scheme supported by the server and additional parameters that are defined for that scheme type.
 
-A server using [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) will respond with a {{HTTPStatus("401")}} `Unauthorized` response to a request for a protected resource.
-This response must include at least one `WWW-Authenticate` header and at least one {{Glossary("challenge")}}, to indicate what authentication schemes can be used to access the resource (and any additional data that each particular scheme needs).
+A server using [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) will respond with a {{HTTPStatus("401", "401 Unauthorized")}} response to a request for a protected resource.
+This response must include at least one `WWW-Authenticate` header and at least one challenge to indicate what authentication schemes can be used to access the resource and any additional data that each particular scheme needs.
 
 Multiple challenges are allowed in one `WWW-Authenticate` header, and multiple `WWW-Authenticate` headers are allowed in one response.
 A server may also include the `WWW-Authenticate` header in other response messages to indicate that supplying credentials might affect the response.
 
 After receiving the `WWW-Authenticate` header, a client will typically prompt the user for credentials, and then re-request the resource.
-This new request uses the {{HTTPHeader("Authorization")}} header to supply the credentials to the server, encoded appropriately for the selected "challenge" authentication method.
+This new request uses the {{HTTPHeader("Authorization")}} header to supply the credentials to the server, encoded appropriately for the selected authentication method.
 The client is expected to select the most secure of the challenges it understands (note that in some cases the "most secure" method is debatable).
 
 <table class="properties">
@@ -31,84 +30,91 @@ The client is expected to select the most secure of the challenges it understand
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
 ## Syntax
 
-At least one challenge must be specified.
-Multiple challenges may be specified, comma-separated, in a single header, or in individual headers:
-
 ```http
-// Challenges specified in single header
-WWW-Authenticate: challenge1, ..., challengeN
+WWW-Authenticate: <challenge>
+```
 
-// Challenges specified in multiple headers
-WWW-Authenticate: challenge1
-...
-WWW-Authenticate: challengeN
+Where a `<challenge>` is comprised of an `<auth-scheme>`, followed by an optional `<token68>` or a comma-separated list of `<auth-params>`:
+
+```plain
+challenge = <auth-scheme> <auth-param>, …, <auth-paramN>
+challenge = <auth-scheme> <token68>
 ```
 
-A single challenge has the following format. Note that the scheme token (`<auth-scheme>`) is mandatory.
-The presence of `realm`, `token68` and any other parameters depends on the definition of the selected scheme.
+For example:
 
 ```http
-// Possible challenge formats (scheme dependent)
 WWW-Authenticate: <auth-scheme>
-WWW-Authenticate: <auth-scheme> realm=<realm>
 WWW-Authenticate: <auth-scheme> token68
-WWW-Authenticate: <auth-scheme> auth-param1=token1, ..., auth-paramN=auth-paramN-token
-WWW-Authenticate: <auth-scheme> realm=<realm> token68
-WWW-Authenticate: <auth-scheme> realm=<realm> token68 auth-param1=auth-param1-token , ..., auth-paramN=auth-paramN-token
-WWW-Authenticate: <auth-scheme> realm=<realm> auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
-WWW-Authenticate: <auth-scheme> token68 auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
+WWW-Authenticate: <auth-scheme> auth-param1=param-token1
+WWW-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN
 ```
 
-For example, [Basic authentication](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme) requires `realm` and allows for optional use of `charset` key, but does not support `token68`.
+The presence of a `token68` or authentication parameters depends on the selected `<auth-scheme>`.
+For example, [Basic authentication](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme) requires a `<realm>`, and allows for optional use of `charset` key, but does not support a `token68`:
 
 ```http
-WWW-Authenticate: Basic realm=<realm>
-WWW-Authenticate: Basic realm=<realm>, charset="UTF-8"
+WWW-Authenticate: Basic realm="Dev", charset="UTF-8"
 ```
 
-## Directives
+Multiple challenges can be sent in a comma-separated list
 
-- `<auth-scheme>`
+```http
+WWW-Authenticate: <challenge>, …, <challengeN>
+```
 
-  - : The [Authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes). Some of the more common types are (case-insensitive): [`Basic`](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.
+Multiple headers can also be sent in a single response:
 
-    > [!NOTE]
-    > For more information/options see [HTTP Authentication > Authentication schemes](/en-US/docs/Web/HTTP/Authentication#authentication_schemes)
+```http
+WWW-Authenticate: <challenge>
+WWW-Authenticate: <challengeN>
+```
 
-- `<realm>` {{optional_inline}}
-  - : A string describing a protected area.
-    A realm allows a server to partition up the areas it protects (if supported by a scheme that allows such partitioning).
-    Some clients show this value to the user to inform them about which particular credentials are required — though most browsers stopped doing so to counter phishing.
-    The only reliably supported character set for this value is `us-ascii`.
-    If no realm is specified, clients often display a formatted hostname instead.
+## Directives
+
+- `<auth-scheme>`
+  - : A case-insensitive token indicating the [Authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes) used.
+    Some of the more common types are [`Basic`](/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.
+    IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), but there are other schemes offered by host services.
+- `<auth-param>` {{optional_inline}}
+  - : An authentication parameter whose format depends on the `<auth-scheme>`.
+    `<realm>` is described below as it's a common authentication parameter among many auth schemes.
+    - `<realm>` {{optional_inline}}
+      - : The string `realm` followed by `=` and a quoted string describing a protected area, for example `realm="staging environment"`.
+        A realm allows a server to partition the areas it protects (if supported by a scheme that allows such partitioning).
+        Some clients show this value to the user to inform them about which particular credentials are required — though most browsers stopped doing so to counter phishing.
+        The only reliably supported character set for this value is `us-ascii`.
+        If no realm is specified, clients often display a formatted hostname instead.
 - `<token68>` {{optional_inline}}
-  - : A token that may be useful for some schemes. The token allows the 66 unreserved URI characters plus a few others.
-    According to the specification, it can hold a base64, base64url, base32, or base16 (hex) encoding, with or without padding, but excluding whitespace.
+  - : A token that may be useful for some schemes.
+    The token allows the 66 unreserved URI characters plus a few others.
+    It can hold a {{glossary("base64")}}, base64url, base32, or base16 (hex) encoding, with or without padding, but excluding whitespace.
+    The token68 alternative to auth-param lists is supported for consistency with legacy authentication schemes.
 
-Other than `<auth-scheme>` and the key `realm`, authorization parameters are specific to each [authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).
-Generally you will need to check the relevant specifications for these (keys for a small subset of schemes are listed below).
+Generally, you will need to check the relevant specifications for the authentication parameters needed for each `<auth-scheme>`.
+The following sections describe token and auth parameters for some common auth schemes.
 
-### Basic
+### Basic authentication directives
 
 - `<realm>`
-  - : As [above](#realm).
-    Note that the realm is mandatory for basic authentication.
+  - : A `<realm>` as [described above](#realm).
+    Note that the realm is mandatory for `Basic` authentication.
 - `charset="UTF-8"` {{optional_inline}}
   - : Tells the client the server's preferred encoding scheme when submitting a username and password.
-    The only allowed value is the case-insensitive string "UTF-8".
+    The only allowed value is the case-insensitive string `UTF-8`.
     This does not relate to the encoding of the realm string.
 
-### Digest
+### Digest authentication directives
 
 - `<realm>` {{optional_inline}}
-  - : String indicating which username/password to use.
+  - : A `<realm>` as [described above](#realm) indicating which username/password to use.
     Minimally should include the host name, but might indicate the users or group that have access.
 - `domain` {{optional_inline}}
   - : A quoted, space-separated list of URI prefixes that define all the locations where the authentication information may be used.
@@ -123,12 +129,12 @@ Generally you will need to check the relevant specifications for these (keys for
     This is opaque to the client. The server is recommended to include Base64 or hexadecimal data.
 - `stale` {{optional_inline}}
   - : A case-insensitive flag indicating that the previous request from the client was rejected because the `nonce` used is too old (stale).
-    If this is `true` the request can be re-tried using the same username/password encrypted using the new `nonce`.
+    If this is `true` the request can be retried using the same username/password encrypted using the new `nonce`.
     If it is any other value then the username/password are invalid and must be re-requested from the user.
 - `algorithm` {{optional_inline}}
-  - : Algorithm used to produce the digest.
-    Valid non-session values are: `"MD5"` (default if not specified), `"SHA-256"`, `"SHA-512"`.
-    Valid session values are: `"MD5-sess"`, `"SHA-256-sess"`, `"SHA-512-sess"`.
+  - : A string indicating the algorithm used to produce a digest.
+    Valid non-session values are: `MD5` (default if `algorithm` not specified), `SHA-256`, `SHA-512`.
+    Valid session values are: `MD5-sess`, `SHA-256-sess`, `SHA-512-sess`.
 - `qop`
   - : Quoted string indicating the quality of protection supported by the server. This must be supplied, and unrecognized options must be ignored.
     - `"auth"`: Authentication
@@ -142,31 +148,49 @@ Generally you will need to check the relevant specifications for these (keys for
 ### HTTP Origin-Bound Authentication (HOBA)
 
 - `<challenge>`
-  - : A set of pairs in the format of '\<len\>:\<value\>' concatenated together to be given to a client.
+  - : A set of pairs in the format of `<len>:<value>` concatenated together to be given to a client.
     The challenge is made of up a nonce, algorithm, origin, realm, key identifier, and the challenge.
 - `<max-age>`
   - : The number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted.
-- `realm` {{optional_inline}}
+- `<realm>` {{optional_inline}}
   - : As above in the [directives](#directives) section.
 
 ## Examples
 
+### Issuing multiple authentication challenges
+
+Multiple challenges may be specified in a single response header:
+
+```http
+HTTP/1.1 401 Unauthorized
+WWW-Authenticate: challenge1, …, challengeN
+```
+
+Multiple challenges can be sent in separate `WWW-Authenticate` headers in the same response:
+
+```http
+HTTP/1.1 401 Unauthorized
+WWW-Authenticate: challenge1
+WWW-Authenticate: challengeN
+```
+
 ### Basic authentication
 
 A server that only supports basic authentication might have a `WWW-Authenticate` response header which looks like this:
 
 ```http
-WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
+HTTP/1.1 401 Unauthorized
+WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
 ```
 
-A user-agent receiving this header would first prompt the user for their username and password, and then re-request the resource: this time including the (encoded) credentials in the {{HTTPHeader("Authorization")}} header.
-The {{HTTPHeader("Authorization")}} header might look like this:
+A user-agent receiving this header would first prompt the user for their username and password, and then re-request the resource with the encoded credentials in the `Authorization` header.
+The `Authorization` header might look like this:
 
 ```http
 Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
 ```
 
-For `"Basic"` authentication the credentials are constructed by first combining the username and the password with a colon (`aladdin:opensesame`), and then by encoding the resulting string in [`base64`](/en-US/docs/Glossary/Base64) (`YWxhZGRpbjpvcGVuc2VzYW1l`).
+For `Basic` authentication, the credentials are constructed by first combining the username and the password with a colon (`aladdin:opensesame`), and then by encoding the resulting string in [`base64`](/en-US/docs/Glossary/Base64) (`YWxhZGRpbjpvcGVuc2VzYW1l`).
 
 > [!NOTE]
 > See also [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) for examples on how to configure Apache or Nginx servers to password protect your site with HTTP basic authentication.
@@ -235,10 +259,11 @@ Authorization: Digest username="Mufasa",
 A server that supports HOBA authentication might have a `WWW-Authenticate` response header which looks like this:
 
 ```http
+HTTP/1.1 401 Unauthorized
 WWW-Authenticate: HOBA max-age="180", challenge="16:MTEyMzEyMzEyMw==1:028:https://www.example.com:80800:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz"
 ```
 
-The to-be-signed blob challenge is made from these parts: `www.example.com` using port 8080, the nonce is '1123123123', the algorithm for signing is RSA-SHA256, the key identifier is 123, and finally the challenge is '68147c97-461b-4310-be9b-4c707237ab53'.
+The to-be-signed blob challenge is made from these parts: `www.example.com` using port 8080, the nonce is `1123123123`, the algorithm for signing is RSA-SHA256, the key identifier is `123`, and finally the challenge is `68147c97-461b-4310-be9b-4c707237ab53`.
 
 A client would receive this header, extract the challenge, sign it with their private key that corresponds to key identifier 123 in our example using RSA-SHA256, and then send the result in the `Authorization` header as a dot-separated key id, challenge, nonce, and signature.
 
diff --git a/files/en-us/web/http/headers/x-content-type-options/index.md b/files/en-us/web/http/headers/x-content-type-options/index.md
index a3c79282cf7dca9..195006cc52f36f6 100644
--- a/files/en-us/web/http/headers/x-content-type-options/index.md
+++ b/files/en-us/web/http/headers/x-content-type-options/index.md
@@ -7,24 +7,13 @@ browser-compat: http.headers.X-Content-Type-Options
 
 {{HTTPSidebar}}
 
-The **`X-Content-Type-Options`** response HTTP 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.
 
-> **Note:** `X-Content-Type-Options` only apply request-blocking [due to `nosniff`](https://fetch.spec.whatwg.org/#ref-for-determine-nosniff) for [request destinations](/en-US/docs/Web/API/Request/destination) of `"script"` and `"style"`.
+> [!NOTE]
+> The `X-Content-Type-Options` header only apply request-blocking [due to `nosniff`](https://fetch.spec.whatwg.org/#ref-for-determine-nosniff) for [request destinations](/en-US/docs/Web/API/Request/destination) of `"script"` and `"style"`.
 > However, it also [enables Cross-Origin Read Blocking (CORB)](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#determining-whether-a-response-is-corb_protected) protection for HTML, TXT, JSON and XML files (excluding SVG `image/svg+xml`).
 
 <table class="properties">
@@ -35,7 +24,7 @@ Site security testers usually expect this header to be set.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -61,11 +50,6 @@ X-Content-Type-Options: nosniff
 
 {{Compat}}
 
-### Browser specific notes
-
-- Firefox 72 enables `X-Content-Type-Options: nosniff` for top-level
-  documents
-
 ## See also
 
 - {{HTTPHeader("Content-Type")}}
diff --git a/files/en-us/web/http/headers/x-dns-prefetch-control/index.md b/files/en-us/web/http/headers/x-dns-prefetch-control/index.md
index 116341586fccc45..03fffd21eef1f16 100644
--- a/files/en-us/web/http/headers/x-dns-prefetch-control/index.md
+++ b/files/en-us/web/http/headers/x-dns-prefetch-control/index.md
@@ -9,14 +9,10 @@ browser-compat: http.headers.X-DNS-Prefetch-Control
 
 {{HTTPSidebar}}{{Non-standard_header}}
 
-The **`X-DNS-Prefetch-Control`** HTTP 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>
@@ -26,7 +22,7 @@ latency when the user clicks a link.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -40,12 +36,10 @@ 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
-- 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.
+- `on`
+  - : 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.
 
 ## Description
 
@@ -117,6 +111,10 @@ affected.
 
 {{Compat}}
 
+## Specifications
+
+Not part of any current specification.
+
 ## See also
 
 - [DNS Prefetching for Firefox (blog post)](https://bitsup.blogspot.com/2008/11/dns-prefetching-for-firefox.html)
diff --git a/files/en-us/web/http/headers/x-forwarded-for/index.md b/files/en-us/web/http/headers/x-forwarded-for/index.md
index ebe81bbba9fcefa..a1b415f044a9b26 100644
--- a/files/en-us/web/http/headers/x-forwarded-for/index.md
+++ b/files/en-us/web/http/headers/x-forwarded-for/index.md
@@ -8,20 +8,13 @@ status:
 
 {{HTTPSidebar}}
 
-The **`X-Forwarded-For`** (XFF) request header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a proxy server.
+The HTTP **`X-Forwarded-For`** (XFF) {{Glossary("request header")}} is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a {{Glossary("proxy server")}}.
 
-> [!WARNING]
-> Improper use of this header can be a security risk. For details, see the [Security and privacy concerns](#security_and_privacy_concerns) section.
-
-When a client connects directly to a server, the
-client's IP address is sent to the server (and is often written to server
-access logs). But if a client connection passes through any [forward or reverse](https://en.wikipedia.org/wiki/Proxy_server) proxies, the server only
-sees the final proxy's IP address, which is often of little use. That's especially true if
-the final proxy is a load balancer which is part of the same installation
-as the server. So, to provide a more-useful client IP address to the server, the `X-Forwarded-For` request header is
-used.
+A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header, although it's much less frequently used.
 
-For detailed guidance on using this header, see the [Parsing](#parsing) and [Selecting an IP address](#selecting_an_ip_address) sections.
+> [!WARNING]
+> Improper use of this header can be a security risk.
+> For details, see the [Security and privacy concerns](#security_and_privacy_concerns) section.
 
 <table class="properties">
   <tbody>
@@ -31,125 +24,117 @@ For detailed guidance on using this header, see the [Parsing](#parsing) and [Sel
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
 
-A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header.
+## Syntax
 
-## Security and privacy concerns
+```http
+X-Forwarded-For: <client>, <proxy>
+X-Forwarded-For: <client>, <proxy>, …, <proxyN>
+```
 
-This header, by design, exposes privacy-sensitive information, such as the IP address
-of the client. Therefore the user's privacy must be kept in mind when deploying this
-header.
+For example, an IPV6 client IP in the first header, an IPV4 client IP in the second header, and an IPV4 client IP and an IPV6 proxy IP in the third example:
 
-The `X-Forwarded-For` header is untrustworthy when no trusted reverse proxy (e.g., a load balancer) is between the client and
-server. If the client and all proxies are benign and well-behaved, then the list of IP addresses in the header
-has the meaning described in the [Directives](#directives) section. But if there's a risk the client or any proxy
-is malicious or misconfigured, then it's possible any part (or the entirety) of the header may have been
-spoofed (and may not be a list or contain IP addresses at all).
+```http
+X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
+X-Forwarded-For: 203.0.113.195
+X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348
+```
 
-If any trusted reverse proxies are between the client and
-server, the final `X-Forwarded-For` IP addresses (one for each trusted proxy) are trustworthy, as they
-were added by trusted proxies. (That's true as long as the server is _only_
-accessible through those proxies and not also directly).
+## Directives
 
-Any security-related use of `X-Forwarded-For` (such as for rate limiting or IP-based
-access control) _must only_ use IP addresses added by a trusted proxy. Using untrustworthy
-values can result in rate-limiter avoidance, access-control bypass, memory exhaustion, or
-other negative security or availability consequences.
+- `<client>`
+  - : The client IP address.
+- `<proxy>`
+  - : A proxy IP address.
+    If a request goes through multiple proxies, the IP addresses of each successive proxy are listed.
+    This means that the rightmost IP address is the IP address of the most recent proxy and the leftmost IP address is the address of the originating client (assuming well-behaved client and proxies).
 
-Conversely, leftmost (untrusted) values must only be used where there will be no negative
-impact from the possibility of using spoofed values.
+## Description
 
-## Syntax
+When a client connects directly to a server, the client's IP address is sent to the server and is often written to server access logs.
+If a client connection passes through any forward or reverse proxies, the server only sees the final proxy's IP address, which is often of little use.
+That's especially true if the final proxy is a load balancer which is part of the same deployment as the server.
+To provide a more useful client IP address to the server, the `X-Forwarded-For` request header is used.
 
-```http
-X-Forwarded-For: <client>, <proxy1>, <proxy2>
-```
+For detailed guidance on using `X-Forwarded-For`, see the [Parsing](#parsing) and [Selecting an IP address](#selecting_an_ip_address) sections.
 
-Elements are comma-separated, with optional whitespace surrounding the commas.
+### Security and privacy concerns
 
-## Directives
+This header exposes privacy-sensitive information by design, such as the IP address of the client.
+Therefore, the user's privacy must be kept in mind when using this header.
 
-- \<client>
-  - : The client IP address
-- \<proxy1>, \<proxy2>
-  - : If a request goes through multiple proxies, the IP addresses of each successive
-    proxy is listed. This means that, given well-behaved client and proxies, the rightmost
-    IP address is the IP address of the most recent proxy and the leftmost IP address is
-    the IP address of the originating client.
+If you know that all proxies in the request chain are trusted (i.e., you control them) and are configured correctly, the parts of the header added by your proxies can be trusted.
+If any proxy is malicious or misconfigured, any part of the header not added by a trusted proxy may be spoofed or may have an unexpected format or contents.
+If the server can be directly connected to from the internet — even if it is also behind a trusted reverse proxy — **no part** of the `X-Forwarded-For` IP list can be considered trustworthy or safe for security-related uses.
 
-## Examples
+Any security-related use of `X-Forwarded-For` (such as for rate limiting or IP-based access control) _must only_ use IP addresses added by a trusted proxy.
+Using untrustworthy values can result in rate-limiter avoidance, access-control bypass, memory exhaustion, or other negative security or availability consequences.
 
-```http
-X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
+Leftmost (untrusted) values must only be used for cases where there is no negative impact from using spoofed values.
 
-X-Forwarded-For: 203.0.113.195
+### Parsing
 
-X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348
+Improper parsing of the `X-Forwarded-For` header may have a negative security impact with consequences as described in the previous section.
+For this reason, the following points should be considered when parsing the header values.
 
-X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178
-```
+There may be multiple `X-Forwarded-For` headers present in a request.
+The IP addresses in these headers must be treated as a single list, starting with the first IP address of the first header and continuing to the last IP address of the last header.
+There are two ways of making this single list:
+
+- Join the `X-Forwarded-For` full header values with commas and then split by comma into a list, or
+- split each `X-Forwarded-For` header by comma into lists and then join the lists.
 
-## Parsing
+It is insufficient to use only one of multiple `X-Forwarded-For` headers.
 
-Improper parsing of the `X-Forwarded-For` header can result in spoofed values being used
-for security-related purposes, resulting in the negative consequences mentioned above.
+Some reverse proxies will automatically join multiple `X-Forwarded-For` headers into one, but it is safer not to assume that this is the case.
 
-There may be multiple `X-Forwarded-For` headers present in a request. The IP addresses in
-these headers must be treated as a single list, starting with the first IP address of the
-first header and continuing to the last IP address of the last header. There are two ways
-of making this single list:
+### Selecting an IP address
 
-- join the `X-Forwarded-For` full header values with commas and then split by comma into a list, or
-- split each `X-Forwarded-For` header by comma into lists and then join the lists
+When selecting an address, the full list of IPs (from all `X-Forwarded-For` headers) must be used.
 
-It is insufficient to use only one of multiple `X-Forwarded-For` headers.
+When choosing the `X-Forwarded-For` IP address closest to the client (untrustworthy and _not_ for security-related purposes), the first IP from the leftmost that is _a valid address_ and _not private/internal_ should be selected.
 
-(Some reverse proxies will automatically join multiple `X-Forwarded-For` headers into one,
-but it is safest to not assume that this is the case.)
+> [!NOTE]
+> We say "a valid address" above because spoofed values may not be actual IP addresses.
+> Additionally, we say "not internal/private" because clients may have used proxies on their internal network, which may have added addresses from the [private IP space](https://en.wikipedia.org/wiki/Private_network).
 
-## Selecting an IP address
+When choosing the first _trustworthy_ `X-Forwarded-For` client IP address, additional configuration is required.
+There are two common methods:
 
-When selecting an address, the full list of IPs — from all `X-Forwarded-For` headers — must be used.
+- Trusted proxy count
+  - : The count of reverse proxies between the internet and the server is configured.
+    The `X-Forwarded-For` IP list is searched from the rightmost by that count minus one.
+    For example, if there is only one reverse proxy, that proxy will add the client's IP address, so the rightmost address should be used.
+    If there are three reverse proxies, the last two IP addresses will be internal.
+- Trusted proxy list
+  - : The IPs or IP ranges of the trusted reverse proxies are configured.
+    The `X-Forwarded-For` IP list is searched from the rightmost, skipping all addresses that are on the trusted proxy list.
+    The first non-matching address is the target address.
 
-When choosing the `X-Forwarded-For` client IP address closest to the client (untrustworthy
-and _not_ for security-related purposes), the first IP from the leftmost that is _a valid
-address_ and _not private/internal_ should be selected. ("Valid" because spoofed values
-may not be IP addresses at all; "not internal/private" because clients may have used
-proxies on their internal network, which may have added addresses from the [private IP space](https://en.wikipedia.org/wiki/Private_network).)
+The first trustworthy `X-Forwarded-For` IP address may belong to an untrusted intermediate proxy rather than the actual client, but it is the only IP suitable to identify a client for security purposes.
 
-When choosing the first _trustworthy_ `X-Forwarded-For` client IP address, additional
-configuration is required. There are two common methods:
+## Examples
 
-- **Trusted proxy count**: The count of reverse proxies between the internet and the
-  server is configured. The `X-Forwarded-For` IP list is searched from the rightmost by
-  that count minus one. (For example, if there is only one reverse proxy, that proxy will
-  add the client's IP address, so the rightmost address should be used. If there are
-  three reverse proxies, the last two IP addresses will be internal.)
-- **Trusted proxy list**: The IPs or IP ranges of the trusted reverse proxies are
-  configured. The `X-Forwarded-For` IP list is searched from the rightmost, skipping all
-  addresses that are on the trusted proxy list. The first non-matching address is the
-  target address.
+### Client and proxy IPs
 
-The first trustworthy `X-Forwarded-For` IP address may belong to an untrusted intermediate
-proxy rather than the actual client computer, but it is the only IP suitable for security
-uses.
+From the following `X-Forwarded-For` request header, we can infer that the client IP address is `203.0.113.195`, and the request has passed through two proxies.
+The first proxy has an IPv6 address of `2001:db8:85a3:8d3:1319:8a2e:370:7348` and the last proxy in the request chain has an IPv4 address of `198.51.100.178`:
 
-Note that if the server is directly connectable from the internet — even if it is also
-behind a trusted reverse proxy — _no part_ of the `X-Forwarded-For` IP list can be
-considered trustworthy or safe for security-related uses.
+```http
+X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178
+```
 
 ## Specifications
 
-Not part of any current specification. The standardized version of this header is
-{{HTTPHeader("Forwarded")}}.
+Not part of any current specification. The standardized version of this header is {{HTTPHeader("Forwarded")}}.
 
 ## See also
 
-- {{HTTPHeader("Forwarded")}}
-- {{HTTPHeader("X-Forwarded-Host")}}
-- {{HTTPHeader("X-Forwarded-Proto")}}
+- {{HTTPHeader("X-Forwarded-Host")}}, {{HTTPHeader("X-Forwarded-Proto")}} headers
 - {{HTTPHeader("Via")}}
+- {{HTTPHeader("Forwarded")}}
+- [What is X-Forwarded-For and when can you trust it?](https://httptoolkit.com/blog/what-is-x-forwarded-for/) httptoolkit.com (2024)
diff --git a/files/en-us/web/http/headers/x-forwarded-host/index.md b/files/en-us/web/http/headers/x-forwarded-host/index.md
index 2fd9b78e86484d8..ff489f387e251ea 100644
--- a/files/en-us/web/http/headers/x-forwarded-host/index.md
+++ b/files/en-us/web/http/headers/x-forwarded-host/index.md
@@ -8,13 +8,11 @@ status:
 
 {{HTTPSidebar}}
 
-The **`X-Forwarded-Host`** (XFH) header is a de-facto standard
-header for identifying the original host requested by the client in the
-{{HTTPHeader("Host")}} HTTP request header.
+The HTTP **`X-Forwarded-Host`** (XFH) {{Glossary("request header")}} is a de-facto standard header for identifying the original host requested by the client in the {{HTTPHeader("Host")}} HTTP request header.
 
-Host names and ports of reverse proxies (load balancers, CDNs) may differ from the
-origin server handling the request, in that case the `X-Forwarded-Host`
-header is useful to determine which Host was originally used.
+Host names and ports of reverse {{Glossary("Proxy_server", "proxies")}} (load balancers, CDNs) may differ from the origin server handling the request, in that case the `X-Forwarded-Host` header is useful to determine which `Host` was originally used.
+
+A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header, although it's much less frequently used.
 
 <table class="properties">
   <tbody>
@@ -24,7 +22,7 @@ header is useful to determine which Host was originally used.
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -37,7 +35,7 @@ X-Forwarded-Host: <host>
 
 ## Directives
 
-- \<host>
+- `<host>`
   - : The domain name of the forwarded server.
 
 ## Examples
@@ -52,7 +50,6 @@ Not part of any current specification.
 
 ## See also
 
+- {{HTTPHeader("X-Forwarded-For")}}, {{HTTPHeader("X-Forwarded-Proto")}} headers
 - {{HTTPHeader("Host")}}
 - {{HTTPHeader("Forwarded")}}
-- {{HTTPHeader("X-Forwarded-For")}}
-- {{HTTPHeader("X-Forwarded-Proto")}}
diff --git a/files/en-us/web/http/headers/x-forwarded-proto/index.md b/files/en-us/web/http/headers/x-forwarded-proto/index.md
index c635f96d36295ff..34f9c713d3bba89 100644
--- a/files/en-us/web/http/headers/x-forwarded-proto/index.md
+++ b/files/en-us/web/http/headers/x-forwarded-proto/index.md
@@ -8,14 +8,12 @@ status:
 
 {{HTTPSidebar}}
 
-The **`X-Forwarded-Proto`** (XFP) header is a de-facto standard
-header for identifying the protocol (HTTP or HTTPS) that a client used to connect to
-your proxy or load balancer. Your server access logs contain the protocol used between
-the server and the load balancer, but not the protocol used between the client and the
-load balancer. To determine the protocol used between the client and the load balancer,
-the `X-Forwarded-Proto` request header can be used.
+The HTTP **`X-Forwarded-Proto`** (XFP) {{Glossary("request header")}} is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to a {{Glossary("Proxy_server", "proxy")}} or load balancer.
 
-A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header.
+Server access logs contain the protocol used between the server and the load balancer, but not the protocol used between the client and the load balancer.
+To determine the protocol used between the client and the load balancer, the `X-Forwarded-Proto` request header can be used.
+
+A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header, although it's much less frequently used.
 
 <table class="properties">
   <tbody>
@@ -25,7 +23,7 @@ A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} he
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -38,16 +36,22 @@ X-Forwarded-Proto: <protocol>
 
 ## Directives
 
-- \<protocol>
-  - : The forwarded protocol (http or https).
+- `<protocol>`
+  - : The forwarded protocol (`http` or `https`).
 
 ## Examples
 
+### X-Forwarded-Proto client protocol
+
+The following header indicates that the original request was made over HTTPS before being forwarded by a proxy or load balancer:
+
 ```http
 X-Forwarded-Proto: https
 ```
 
-Other non-standard forms:
+### Non-standard forms
+
+The following forms may be seen in request headers:
 
 ```http
 # Microsoft
@@ -60,11 +64,9 @@ X-Url-Scheme: https
 
 ## Specifications
 
-Not part of any current specification. The standardized version of this header is
-{{HTTPHeader("Forwarded")}}.
+Not part of any current specification. The standardized version of this header is {{HTTPHeader("Forwarded")}}.
 
 ## See also
 
+- {{HTTPHeader("X-Forwarded-Host")}}, {{HTTPHeader("X-Forwarded-For")}} headers
 - {{HTTPHeader("Forwarded")}}
-- {{HTTPHeader("X-Forwarded-For")}}
-- {{HTTPHeader("X-Forwarded-Host")}}
diff --git a/files/en-us/web/http/headers/x-frame-options/index.md b/files/en-us/web/http/headers/x-frame-options/index.md
index 5b768ff810814e2..b31314a6fa5ba24 100644
--- a/files/en-us/web/http/headers/x-frame-options/index.md
+++ b/files/en-us/web/http/headers/x-frame-options/index.md
@@ -12,7 +12,7 @@ browser-compat: http.headers.X-Frame-Options
 > [!WARNING]
 > Instead of this header, use the {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}} directive in a {{HTTPHeader("Content-Security-Policy")}} header.
 
-The **`X-Frame-Options`** [HTTP](/en-US/docs/Web/HTTP) response header can be used to indicate whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}. Sites can use this to avoid [click-jacking](/en-US/docs/Web/Security/Types_of_attacks#click-jacking) attacks, by ensuring that their content is not embedded into other sites.
+The HTTP **`X-Frame-Options`** {{Glossary("response header")}} can be used to indicate whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}. Sites can use this to avoid [click-jacking](/en-US/docs/Web/Security/Types_of_attacks#click-jacking) attacks, by ensuring that their content is not embedded into other sites.
 
 The added security is provided only if the user accessing the document is using a browser that supports `X-Frame-Options`.
 
@@ -24,7 +24,7 @@ The added security is provided only if the user accessing the document is using
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
diff --git a/files/en-us/web/http/headers/x-powered-by/index.md b/files/en-us/web/http/headers/x-powered-by/index.md
new file mode 100644
index 000000000000000..07aa420a8d4c895
--- /dev/null
+++ b/files/en-us/web/http/headers/x-powered-by/index.md
@@ -0,0 +1,55 @@
+---
+title: X-Powered-By
+slug: Web/HTTP/Headers/X-Powered-By
+page-type: http-header
+status:
+  - non-standard
+---
+
+{{HTTPSidebar}}
+
+The HTTP **`X-Powered-By`** {{Glossary("response header")}} is a non-standard header for identifying the application or framework that generated the response.
+
+<table class="properties">
+  <tbody>
+    <tr>
+      <th scope="row">Header type</th>
+      <td>{{Glossary("Response header")}}</td>
+    </tr>
+    <tr>
+      <th scope="row">{{Glossary("Forbidden response header name")}}</th>
+      <td>No</td>
+    </tr>
+  </tbody>
+</table>
+
+## Syntax
+
+```http
+X-Powered-By: <application>
+```
+
+## Directives
+
+- `<application>`
+  - : A string describing the server application or framework.
+
+## Examples
+
+### Express X-Powered-By header
+
+Express applications will usually include the `X-Powered-By` header in responses with the string `express` as the field value:
+
+```http
+X-Powered-By: express
+```
+
+## Specifications
+
+Not part of any current specification.
+
+## See also
+
+- {{HTTPHeader("X-Forwarded-Host")}}, {{HTTPHeader("X-Forwarded-For")}}, {{HTTPHeader("X-Forwarded-Proto")}} headers
+- {{HTTPHeader("Via")}}
+- {{HTTPHeader("Forwarded")}}
diff --git a/files/en-us/web/http/headers/x-xss-protection/index.md b/files/en-us/web/http/headers/x-xss-protection/index.md
index 434a7c9c1b05073..be0563306510013 100644
--- a/files/en-us/web/http/headers/x-xss-protection/index.md
+++ b/files/en-us/web/http/headers/x-xss-protection/index.md
@@ -3,24 +3,21 @@ title: X-XSS-Protection
 slug: Web/HTTP/Headers/X-XSS-Protection
 page-type: http-header
 status:
+  - deprecated
   - non-standard
 browser-compat: http.headers.X-XSS-Protection
 ---
 
-{{HTTPSidebar}}{{Non-standard_header}}
-
-The HTTP **`X-XSS-Protection`** response header was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting ({{Glossary("Cross-site_scripting", "XSS")}}) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong {{HTTPHeader("Content-Security-Policy")}} that disables the use of inline JavaScript (`'unsafe-inline'`).
+{{HTTPSidebar}}{{Non-standard_header}}{{deprecated_header}}
 
 > [!WARNING]
-> Even though this feature can protect users of older web browsers that don't yet support {{Glossary("CSP")}}, in some cases, **XSS protection can create XSS vulnerabilities** in otherwise safe websites. See the section below for more information.
+> Even though this feature can protect users of older web browsers that don't support {{Glossary("CSP")}}, in some cases, **`X-XSS-Protection` can create XSS vulnerabilities** in otherwise safe websites.
+> See the [Security considerations](#security_considerations) section below for more information.
+
+The HTTP **`X-XSS-Protection`** {{Glossary("response header")}} was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting ({{Glossary("Cross-site_scripting", "XSS")}}) attacks.
+These protections are largely unnecessary in modern browsers when sites implement a strong {{HTTPHeader("Content-Security-Policy")}} that disables the use of inline JavaScript (`'unsafe-inline'`).
 
-> [!NOTE]
->
-> - Chrome has [removed their XSS Auditor](https://chromestatus.com/feature/5021976655560704)
-> - Firefox has not, and [will not implement `X-XSS-Protection`](https://bugzil.la/528661)
-> - Edge has [retired their XSS filter](https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10-insider-preview-build-17723-and-build-18204/)
->
-> This means that if you do not need to support legacy browsers, it is recommended that you use [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) without allowing `unsafe-inline` scripts instead.
+It is recommended that you use [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) instead of XSS filtering.
 
 <table class="properties">
   <tbody>
@@ -30,7 +27,7 @@ The HTTP **`X-XSS-Protection`** response header was a feature of Internet Explor
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
-      <td>no</td>
+      <td>No</td>
     </tr>
   </tbody>
 </table>
@@ -44,16 +41,20 @@ X-XSS-Protection: 1; mode=block
 X-XSS-Protection: 1; report=<reporting-uri>
 ```
 
-- 0
+## Directives
+
+- `0`
   - : Disables XSS filtering.
-- 1
+- `1`
   - : Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
-- 1; mode=block
+- `1; mode=block`
   - : Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
-- 1; report=\<reporting-URI> (Chromium only)
+- `1; report=<reporting-URI>` (Chromium only)
   - : Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP {{CSP("report-uri")}} directive to send a report.
 
-## Vulnerabilities caused by XSS filtering
+## Security considerations
+
+### Vulnerabilities caused by XSS filtering
 
 Consider the following excerpt of HTML code for a webpage:
 
diff --git a/files/en-us/web/http/messages/index.md b/files/en-us/web/http/messages/index.md
index bb2635aa4f49857..b0fb78d56591bf4 100644
--- a/files/en-us/web/http/messages/index.md
+++ b/files/en-us/web/http/messages/index.md
@@ -116,7 +116,7 @@ Content-Length: 50
 
 In HTTP/1.x, each header is a **case-insensitive** string followed by a colon (`:`) and a value whose format depends on the header.
 The whole header, including the value, consists of one single line.
-This line can be quite long in some cases, such as the {{HTTPHEader("Cookie")}} header.
+This line can be quite long in some cases, such as the {{HTTPHeader("Cookie")}} header.
 
 ![Example of headers in an HTTP request](https://mdn.github.io/shared-assets/images/diagrams/http/messages/request-headers.svg)