chore(http): Refresh headers ~[s->x]

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 transformed code back to a source, enabling the browser to reconstruct the original source code and show that reconstructed code in the debugger.
+
+The JavaScript sources executed by the browser are often transformed in some way from the sources 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)

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)

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

@@ -325,7 +325,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")}}

files/en-us/web/http/headers/no-vary-search/index.md

@@ -132,3 +132,8 @@ No-Vary-Search: params, except=("id")
 ## Browser compatibility
 
 {{Compat}}
+
+## See also
+
+- [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API)
+- [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header

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 set {{HTTPHeader("Vary", "Vary: Service-Worker-Navigation-Preload")}} 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.
+### Using Service-Worker-Navigation-Preload
+
+The header below is sent by default in 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)

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>
@@ -167,9 +167,10 @@ 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
 
@@ -252,10 +253,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)

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,25 +26,25 @@ 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>
 
 ## 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.

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

@@ -7,7 +7,7 @@ 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")}} links generated code to a {{Glossary("source map")}}, enabling the browser to reconstruct the original source and present the reconstructed original in the debugger.
 
 <table class="properties">
   <tbody>
@@ -17,7 +17,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,11 +31,15 @@ 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 `SourceMap`
+
+The following response contains an absolute
+
 ```http
 SourceMap: /path/to/file.js.map
 ```
@@ -50,4 +54,5 @@ 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)

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"