From a848f0aa8ceead5671fda22d5e9071174d259023 Mon Sep 17 00:00:00 2001 From: Brian Thomas Smith Date: Wed, 30 Oct 2024 17:30:44 +0100 Subject: [PATCH 1/3] chore(http): Refresh headers r-s --- .../web/http/headers/repr-digest/index.md | 82 +++++++++++++------ .../web/http/headers/retry-after/index.md | 32 +++----- files/en-us/web/http/headers/rtt/index.md | 34 ++++---- .../en-us/web/http/headers/save-data/index.md | 52 ++++++------ .../http/headers/sec-browsing-topics/index.md | 4 +- .../sec-ch-prefers-color-scheme/index.md | 14 ++-- .../sec-ch-prefers-reduced-motion/index.md | 13 +-- .../index.md | 11 +-- .../web/http/headers/sec-ch-ua-arch/index.md | 10 ++- .../http/headers/sec-ch-ua-bitness/index.md | 12 +-- .../sec-ch-ua-full-version-list/index.md | 40 +++++---- .../headers/sec-ch-ua-full-version/index.md | 10 ++- .../http/headers/sec-ch-ua-mobile/index.md | 11 +-- .../web/http/headers/sec-ch-ua-model/index.md | 12 +-- .../sec-ch-ua-platform-version/index.md | 15 ++-- .../http/headers/sec-ch-ua-platform/index.md | 11 +-- .../en-us/web/http/headers/sec-ch-ua/index.md | 50 +++++------ .../web/http/headers/sec-fetch-dest/index.md | 16 ++-- .../web/http/headers/sec-fetch-mode/index.md | 18 ++-- .../web/http/headers/sec-fetch-site/index.md | 15 ++-- .../web/http/headers/sec-fetch-user/index.md | 15 ++-- files/en-us/web/http/headers/sec-gpc/index.md | 13 ++- .../web/http/headers/sec-purpose/index.md | 7 +- .../headers/sec-websocket-accept/index.md | 14 ++-- .../headers/sec-websocket-extensions/index.md | 6 +- .../http/headers/sec-websocket-key/index.md | 12 +-- .../headers/sec-websocket-protocol/index.md | 6 +- .../headers/sec-websocket-version/index.md | 8 +- 28 files changed, 289 insertions(+), 254 deletions(-) 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 49004a64d723539..5539721d286baca 100644 --- a/files/en-us/web/http/headers/repr-digest/index.md +++ b/files/en-us/web/http/headers/repr-digest/index.md @@ -7,7 +7,9 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc9530 {{HTTPSidebar}} -The **`Repr-Digest`** response or request header provides a {{Glossary("digest")}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. It is invariant under e.g., {{HTTPHeader("Content-Encoding")}} or {{HTTPHeader("Content-Range")}}, which do affect the {{HTTPHeader("Content-Digest")}}. Furthermore, [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representations with different representation digests. +The HTTP **`Repr-Digest`** {{Glossary("Request header", "request")}} and {{Glossary("Response header", "response header")}} provides a {{Glossary("digest")}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. +Variants in {{HTTPHeader("Content-Encoding")}} and {{HTTPHeader("Content-Range")}}, for example, have no influence on the `Repr-Digest` digests, as opposed to the {{HTTPHeader("Content-Digest")}}, which does vary based on such changes to message content. +Furthermore, [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representations which results in different representation digests. @@ -17,104 +19,130 @@ The **`Repr-Digest`** response or request header provides a {{Glossary("digest") - +
{{Glossary("Forbidden header name")}}noNo
## Syntax -`Repr-Digest` describes an [RFC8941 dictionary](https://www.rfc-editor.org/rfc/rfc8941#section-3.2) with its keys being names of digest algorithms and its values being the digest in bytes (or an integer digest for legacy digest algorithms). +```http +Repr-Digest: = -> [!NOTE] -> In contrast to earlier drafts of the specification, the standard-base64-encoded digest bytes are wrapped in colons (`:`, ASCII 0x3A) as part of the [dictionary syntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences). +// Multiple digest algorithms +Repr-Digest: =,= +``` ## Directives -### Digest algorithms - -Only two digest algorithms are currently registered and not considered insecure: `sha-512` and `sha-256`. +- `` + - : The algorithm used to create a digest of the representation. + Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`. + The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`. +- `` + - : The digest in bytes of the representation using the ``. + The choice of digest algorithm also determines the encoding to use: `sha-512` and `sha-256` use base64 encoding, while some legacy digest algorithms such as `unixsum` use a decimal integer. + In contrast to earlier drafts of the specification, the standard-base64-encoded digest bytes are wrapped in colons (`:`, ASCII 0x3A) as part of the [dictionary syntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences). -The registered insecure digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`. +### Usage notes -Usage of digest algorithms which are considered insecure is discouraged as collisions can realistically be forced, rendering the digest's usefulness weak. Unless when working with legacy systems (which is unlikely since most will expect the legacy {{HTTPHeader("Digest")}} header and not understand this specification), consider not emitting a `Repr-Digest` instead of emitting one using an insecure digest algorithm. +Usage of digest algorithms which are considered insecure is discouraged as collisions can realistically be forced, rendering the digest's usefulness weak. +Unless working with legacy systems (which is unlikely since most will expect the legacy {{HTTPHeader("Digest")}} header and not understand this specification), consider omitting a `Repr-Digest` instead of including one with an insecure digest algorithm. ## Examples ### HTTP response where `Repr-Digest` and `Content-Digest` coincide -An HTTP server may send content octets equivalent to the selected representation's octets: +An HTTP server may send content octets equivalent to the selected representation's octets. +In this case, `Repr-Digest` and `Content-Digest` have equal values for the same digest algorithms: ```http -... +… Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=: Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=: -... +… Content-Type: text/yaml Content-Encoding: identity Content-Length: 38054 Content-Range: 0-38053/38054 -... +… + +[message body] ``` ### HTTP responses where `Repr-Digest` and `Content-Digest` diverge -A static file server may however choose to compress an HTML page, resulting in differing {{HTTPHeader("Content-Digest")}} and `Repr-Digest` header values: +A static file server may compress an HTML page, meaning the {{HTTPHeader("Content-Digest")}} will have a different value to the `Repr-Digest` header in a response, given the same digest algorithm: ```http -... +… Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==: Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809 -... +… Content-Type: text/html; charset=utf-8 Content-Encoding: br -... +… -... +[message body] ``` +In another response, the server uses a different compression method, resulting in a new `Content-Digest`, but the same `Repr-Digest` digests: + ```http -... +… Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==: Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=: -... +… Content-Type: text/html; charset=utf-8 Content-Encoding: deflate, deflate, deflate -... +… -... +[message body] ``` ### Successful HTTP request-response employing `Want-Repr-Digest`, `Repr-Digest`, and `Content-Digest` +The following {{HTTPMethod("PUT")}} request includes a `Want-Repr-Digest` header, indicating that the server should include a `Repr-Digest` header with a `sha-256` digest if the operation is successful: + ```http PUT /api/transact HTTP/1.1 Want-Repr-Digest: sha-256=8 Content-Type: text/json -... +… + +[message body] ``` +The server responds with a successful {{HTTPStatus("201", "201 Created")}} response, including `Repr-Digest` and `Content-Digest` headers with sha-256 digests of the representation and content, respectively: + ```http HTTP/1.1 201 Created Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=: Content-Encoding: br Content-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=: -... +… + +[message body] ``` ### Unsuccessful HTTP request-response employing `Repr-Digest` +In the following message, a client requests a resource with a specific sha-256 digest: + ```http GET /api/last-transaction HTTP/1.1 Accept: text/json Repr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=: -... +… ``` +A {{HTTPStatus("406", "406 Not Acceptable")}} is returned by the server to indicate the operation failed given a specific digest for the resource. +A `Repr-Digest` header is included with the SHA-256 digest value that would result in a successful response if the client repeated the request with that value: + ```http HTTP/1.1 406 Not Acceptable Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=: -... +… ``` ## Specifications diff --git a/files/en-us/web/http/headers/retry-after/index.md b/files/en-us/web/http/headers/retry-after/index.md index b937e26897011c9..8d6c544dcaa83af 100644 --- a/files/en-us/web/http/headers/retry-after/index.md +++ b/files/en-us/web/http/headers/retry-after/index.md @@ -7,17 +7,12 @@ browser-compat: http.headers.Retry-After {{HTTPSidebar}} -The **`Retry-After`** response HTTP header indicates how long -the user agent should wait before making a follow-up request. There are three main cases -this header is used: - -- When sent with a {{HTTPStatus(503)}} (Service Unavailable) response, this indicates - how long the service is expected to be unavailable. -- When sent with a {{HTTPStatus(429)}} (Too Many Requests) response, this indicates - how long to wait before making a new request. -- When sent with a redirect response, such as {{HTTPStatus(301)}} (Moved Permanently), - this indicates the minimum time that the user agent is asked to wait before issuing - the redirected request. +The HTTP **`Retry-After`** {{Glossary("response header")}} indicates how long the user agent should wait before making a follow-up request. +There are three main cases this header is used: + +- In a {{HTTPStatus("503", "503 Service Unavailable")}} response, this indicates how long the service is expected to be unavailable. +- In a {{HTTPStatus("429", "429 Too Many Requests")}} response, this indicates how long to wait before making a new request. +- In a redirect response, such as {{HTTPStatus("301", "301 Moved Permanently")}}, this indicates the minimum time that the user agent is asked to wait before issuing the redirected request. @@ -27,7 +22,7 @@ this header is used: - +
{{Glossary("Forbidden header name")}}noNo
@@ -41,10 +36,10 @@ Retry-After: ## Directives -- \ +- `` - : A date after which to retry. See the {{HTTPHeader("Date")}} header for more details on the HTTP date format. -- \ +- `` - : A non-negative decimal integer indicating the seconds to delay after the response is received. @@ -54,8 +49,7 @@ Retry-After: Support for the `Retry-After` header on both clients and servers is still inconsistent. However, some crawlers and spiders, like the Googlebot, honor the -`Retry-After` header. It is useful to send it along with a -{{HTTPStatus(503)}} (Service Unavailable) response, so that search engines will keep +`Retry-After` header. It is useful to send it along with a `503` response, so that search engines will keep indexing your site when the downtime is over. ```http @@ -73,6 +67,6 @@ Retry-After: 120 ## See also -- [Google Webmaster blog: How to deal with planned site downtime](https://webmasters.googleblog.com/2011/01/how-to-deal-with-planned-site-downtime.html) -- {{HTTPStatus(503)}} (Service Unavailable) -- {{HTTPStatus(301)}} (Moved Permanently) +- {{HTTPStatus("503", "503 Service Unavailable")}} +- {{HTTPStatus("301", "301 Moved Permanently")}} +- [How to deal with planned site downtime](https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime) on developers.google.com (2011) diff --git a/files/en-us/web/http/headers/rtt/index.md b/files/en-us/web/http/headers/rtt/index.md index b82db67d0b5e1ed..d2b01daf4f3f953 100644 --- a/files/en-us/web/http/headers/rtt/index.md +++ b/files/en-us/web/http/headers/rtt/index.md @@ -9,7 +9,15 @@ browser-compat: http.headers.RTT {{HTTPSidebar}} {{SeeCompatTable}} -The **`RTT`** [Client hint](/en-US/docs/Web/HTTP/Client_hints) request header field provides the approximate round trip time on the application layer, in milliseconds. The RTT hint, unlike transport layer RTT, includes server processing time. +The HTTP **`RTT`** {{Glossary("request header")}} is a [network client hint](/en-US/docs/Web/HTTP/Client_hints#network_client_hints) which provides the approximate round trip time on the application layer, in milliseconds. +The RTT hint includes server processing time, unlike transport layer RTT. + +The RTT value is rounded to the nearest 25 milliseconds to prevent [fingerprinting](/en-US/docs/Glossary/Fingerprinting), although there are many other mechanisms an attacker might use to obtain similar round-trip information. + +The hint allows a server to choose what information is sent based on the network responsiveness/latency. For example, it might choose to send fewer resources. + +> [!NOTE] +> The {{HTTPHeader("Vary")}} header is used in responses to indicate that a different resource is sent for every different value of the header (see [HTTP Caching Vary](/en-US/docs/Web/HTTP/Caching#vary)). Even if `RTT` is used to configure what resources are sent consider omitting it in the {{HTTPHeader("Vary")}} header — it is likely to change often, which effectively makes the resource uncacheable. @@ -22,18 +30,11 @@ The **`RTT`** [Client hint](/en-US/docs/Web/HTTP/Client_hints) request header fi - +
{{Glossary("Forbidden header name")}}noNo
-The RTT value is rounded to the nearest 25 milliseconds to prevent [fingerprinting](/en-US/docs/Glossary/Fingerprinting). There are many other mechanisms an attacker might use to obtain similar round-trip information. - -The hint allows a server to choose what information is sent based on the network responsiveness/latency. For example, it might choose to send fewer resources. - -> [!NOTE] -> The {{HTTPHeader("Vary")}} header is used in responses to indicate that a different resource is sent for every different value of the header (see [HTTP Caching Vary](/en-US/docs/Web/HTTP/Caching#vary)). Even if `RTT` is used to configure what resources are sent consider omitting it in the {{HTTPHeader("Vary")}} header — it is likely to change often, which effectively makes the resource uncacheable. - ## Syntax ```http @@ -42,11 +43,13 @@ RTT: ## Directives -- \ +- `` - : The approximate round trip time in milliseconds, rounded to the nearest 25 milliseconds. ## Examples +### Using RTT client hints + A server first needs to opt in to receive the `RTT` header by sending the {{HTTPHeader("Accept-CH")}} response header containing `RTT`. ```http @@ -69,13 +72,8 @@ RTT: 125 ## 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) -- Network client hints - - - {{HTTPHeader("Downlink")}} - - {{HTTPHeader("ECT")}} - - {{HTTPHeader("Save-Data")}} - +- {{HTTPHeader("Downlink")}}, {{HTTPHeader("ECT")}}, {{HTTPHeader("Save-Data")}} network 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")}} - {{domxref("NetworkInformation.effectiveType")}} +- [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/save-data/index.md b/files/en-us/web/http/headers/save-data/index.md index 0872427e43a2b41..bca0da1cf54fe23 100644 --- a/files/en-us/web/http/headers/save-data/index.md +++ b/files/en-us/web/http/headers/save-data/index.md @@ -9,12 +9,16 @@ browser-compat: http.headers.Save-Data {{HTTPSidebar}}{{SeeCompatTable}} -The **`Save-Data`** [network client hint](/en-US/docs/Web/HTTP/Client_hints#network_client_hints) request header field is a boolean which indicates the client's preference for reduced data usage. +The HTTP **`Save-Data`** {{Glossary("request header")}} is a [network client hint](/en-US/docs/Web/HTTP/Client_hints#network_client_hints) which indicates the client's preference for reduced data usage. This could be for reasons such as high transfer costs, slow connection speeds, etc. -**`Save-Data`** is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints), and hence may be sent by the client even if not requested by the server using an {{HTTPHeader("Accept-CH")}} response header. +`Save-Data` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints), and hence may be sent by the client even if not requested by the server using an {{HTTPHeader("Accept-CH")}} response header. Further, it should be used to reduce data sent to the client irrespective of the values of other client hints that indicate network capability, like {{HTTPHeader("Downlink")}} and {{HTTPHeader("RTT")}}. +> [!NOTE] +> Disabling HTTP/2 Server Push ({{RFC("7540", "Server Push", "8.2")}}) may reduce data downloads. +> Note that this feature is no longer supported by default in most major browser engines. + @@ -26,26 +30,17 @@ Further, it should be used to reduce data sent to the client irrespective of the - + - +
{{Glossary("Forbidden header name")}}noNo
{{Glossary("CORS-safelisted response header")}} noNo
-A value of `On` indicates explicit user opt-in into a reduced data usage -mode on the client, and when communicated to origins allows them to deliver alternative -content to reduce the data downloaded such as smaller image and video resources, -different markup and styling, disabled polling and automatic updates, and so on. - -> [!NOTE] -> Disabling HTTP/2 Server Push ({{RFC("7540", "Server Push", "8.2")}}) may reduce data downloads. -> Note that this feature is no longer supported by default in most major browser engines. - ## Syntax ```http @@ -58,15 +53,16 @@ Save-Data: - : A value indicating whether the client wants to opt in to reduced data usage mode. `on` indicates yes, while `off` (the default) indicates no. -## Examples +### Description -The {{HTTPHeader("Vary")}} header ensures that the content is cached properly (for -instance ensuring that the user is not served a lower-quality image from the cache when -`Save-Data` header is no longer present \[_e.g._ after having switched from cellular to Wi-Fi]). +A value of `On` indicates explicit user opt-in into a reduced data usage mode on the client. +When communicated to origins, this allows them to deliver alternative content to reduce the data downloaded such as smaller image and video resources, different markup and styling, disabled polling and automatic updates, and so on. -### With `Save-Data: on` +## Examples -Request: +### Using `Save-Data: on` + +The following message requests a resource with `Save-Data` header indicating the client is opting in to reduced data mode: ```http GET /image.jpg HTTP/1.1 @@ -74,7 +70,7 @@ Host: example.com Save-Data: on ``` -Response: +The server responds with a `200` response, and the {{HTTPHeader("Vary")}} header indicates that `Save-Data` may have been used to create the response, and caches should be aware of this header to differentiate responses: ```http HTTP/1.1 200 OK @@ -86,16 +82,18 @@ Content-Type: image/jpeg […] ``` -### Without `Save-Data` +### Omitting `Save-Data` -Request: +In this case, the client requests the same resource without the `Save-Data` header: ```http GET /image.jpg HTTP/1.1 Host: example.com ``` -Response: +The server's response provides the full version of the content. +The {{HTTPHeader("Vary")}} header ensures that responses should be separately cached based on the value of the `Save-Data` header. +This can ensure that the user is not served a lower-quality image from the cache when the `Save-Data` header is no longer present (e.g., after having switched from cellular to Wi-Fi). ```http HTTP/1.1 200 OK @@ -117,9 +115,9 @@ Content-Type: image/jpeg ## See also -- [Help Your Users `Save-Data` - CSS Tricks](https://css-tricks.com/help-users-save-data/) -- [Delivering Fast and Light Applications with Save-Data - web.dev](https://web.dev/articles/optimizing-content-efficiency-save-data) -- {{HTTPHeader("Vary")}} header which indicates that the content served varies depending on the value of `Save-Data` (see [HTTP Caching > Vary](/en-US/docs/Web/HTTP/Caching#vary)) - CSS @media feature [`prefers-reduced-data`](/en-US/docs/Web/CSS/@media/prefers-reduced-data) {{experimental_inline}} -- [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) +- {{HTTPHeader("Vary")}} header which indicates that the content served varies depending on the value of `Save-Data` (see [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary)) - {{domxref("NetworkInformation.saveData")}} +- [Help Your Users `Save-Data`](https://css-tricks.com/help-users-save-data/) on css-tricks.com +- [Delivering Fast and Light Applications with Save-Data - web.dev](https://web.dev/articles/optimizing-content-efficiency-save-data) on web.dev +- [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/sec-browsing-topics/index.md b/files/en-us/web/http/headers/sec-browsing-topics/index.md index 68a2bc025e06f6c..1e1696e83488654 100644 --- a/files/en-us/web/http/headers/sec-browsing-topics/index.md +++ b/files/en-us/web/http/headers/sec-browsing-topics/index.md @@ -16,7 +16,7 @@ browser-compat: http.headers.Sec-Browsing-Topics > [!NOTE] > An [Enrollment process](/en-US/docs/Web/Privacy/Privacy_sandbox/Enrollment) is required to use this feature in your applications. -The **`Sec-Browsing-Topics`** request header sends the selected topics for the current user along with the associated request, which are used by an ad tech platform to choose a personalized ad to display. +The HTTP **`Sec-Browsing-Topics`** {{Glossary("request header")}} sends the selected topics for the current user along with the associated request, which are used by an ad tech platform to choose a personalized ad to display. If the calling site does not have the Topics API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Privacy_sandbox/Enrollment), attempting to create or modify `Sec-Browsing-Topics` fails silently, and any existing `Sec-Browsing-Topics` header is deleted. @@ -30,7 +30,7 @@ See [Using the Topics API](/en-US/docs/Web/API/Topics_API/Using) for more detail {{Glossary("Forbidden header name")}} - yes (prefix Sec-) + Yes (Sec- prefix) diff --git a/files/en-us/web/http/headers/sec-ch-prefers-color-scheme/index.md b/files/en-us/web/http/headers/sec-ch-prefers-color-scheme/index.md index efa9126c2d270fd..7e845492ce26890 100644 --- a/files/en-us/web/http/headers/sec-ch-prefers-color-scheme/index.md +++ b/files/en-us/web/http/headers/sec-ch-prefers-color-scheme/index.md @@ -9,7 +9,8 @@ browser-compat: http.headers.Sec-CH-Prefers-Color-Scheme {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-Prefers-Color-Scheme`** [user preference media feature client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) request header provides the user's preference for light or dark color themes. A user indicates their preference through an operating system setting (for example, light or dark mode) or a user agent setting. +The HTTP **`Sec-CH-Prefers-Color-Scheme`** {{Glossary("request header")}} is a [media feature client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) which provides the user's preference for light or dark color themes. +A user indicates their preference through an operating system setting (for example, light or dark mode) or a user agent setting. If a server signals to a client via the {{httpheader("Accept-CH")}} header that it accepts `Sec-CH-Prefers-Color-Scheme`, the client can then respond with this header to indicate the user's preference for a specific color scheme. The server can send the client appropriately adapted content including images or CSS to display a light or dark mode for subsequent rendered content. @@ -26,7 +27,7 @@ This header is modeled on the {{cssxref("@media/prefers-color-scheme", "prefers- {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -48,12 +49,13 @@ Sec-CH-Prefers-Color-Scheme: ### Directives - `` - - : A string indicating the user agent's preference for dark or light content: `"light"` or `"dark"`. The value may originate from a corresponding setting in the underlying operating system. ## Examples +### Using Sec-CH-Prefers-Color-Scheme + The client makes an initial request to the server: ```http @@ -96,8 +98,8 @@ The client will include the header in subsequent requests in the current session ## See also - [Client hints](/en-US/docs/Web/HTTP/Client_hints) -- [`prefers-color-scheme` CSS Media Query](/en-US/docs/Web/CSS/@media/prefers-color-scheme) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{HTTPHeader("Accept-CH")}} -- [HTTP Caching varying responses](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} +- [HTTP Caching varying responses](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} header +- [`prefers-color-scheme` CSS Media Query](/en-US/docs/Web/CSS/@media/prefers-color-scheme) +- [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/sec-ch-prefers-reduced-motion/index.md b/files/en-us/web/http/headers/sec-ch-prefers-reduced-motion/index.md index 5b93fe34d4f3ef8..76ba7862929f956 100644 --- a/files/en-us/web/http/headers/sec-ch-prefers-reduced-motion/index.md +++ b/files/en-us/web/http/headers/sec-ch-prefers-reduced-motion/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-Prefers-Reduced-Motion {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-Prefers-Reduced-Motion`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) request header indicates the user agent's preference for animations to be displayed with reduced motion. +The HTTP **`Sec-CH-Prefers-Reduced-Motion`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) which indicates the user agent's preference for animations to be displayed with reduced motion. If a server signals to a client via the {{httpheader("Accept-CH")}} header that it accepts `Sec-CH-Prefers-Reduced-Motion`, the client can then respond with this header to indicate the user's preference for reduced motion. The server can send the client appropriately adapted content, for example, JavaScript or CSS, to reduce the motion of any animations presented on subsequent rendered content. This could include reducing the speed or amplitude of movement to reduce discomfort for those with vestibular motion disorders. @@ -26,7 +26,7 @@ This header is modeled on the {{cssxref("@media/prefers-reduced-motion", "prefer {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -40,11 +40,12 @@ Sec-CH-Prefers-Reduced-Motion: ### Directives - `` - - : The user agent's preference for reduced-motion animations. This is often taken from the underlying operating system's setting. The value of this directive can be either `no-preference` or `reduce`. ## Examples +### Using Sec-CH-Prefers-Reduced-Motion + The client makes an initial request to the server: ```http @@ -86,8 +87,8 @@ The client will include the header in subsequent requests in the current session ## See also - [Client hints](/en-US/docs/Web/HTTP/Client_hints) -- [`prefers-reduced-motion` CSS Media Query](/en-US/docs/Web/CSS/@media/prefers-reduced-motion) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{HTTPHeader("Accept-CH")}} -- [HTTP Caching > Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}} +- [`prefers-reduced-motion` CSS Media Query](/en-US/docs/Web/CSS/@media/prefers-reduced-motion) +- [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/sec-ch-prefers-reduced-transparency/index.md b/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md index a552b840b0dc024..e3e6b4963a09bdf 100644 --- a/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md +++ b/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-Prefers-Reduced-Transparency {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-Prefers-Reduced-Transparency`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) request header indicates the user agent's preference for reduced transparency. +The HTTP **`Sec-CH-Prefers-Reduced-Transparency`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) which indicates the user agent's preference for reduced transparency. If a server signals to a client via the {{httpheader("Accept-CH")}} header that it accepts `Sec-CH-Prefers-Reduced-Transparency`, the client can then respond with this header to indicate the user's preference for reduced transparency. The server can send the client appropriately adapted content — for example, CSS or images — to reduce the transparency of the content. @@ -26,7 +26,7 @@ This header is modeled on the {{cssxref("@media/prefers-reduced-transparency", " {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -40,11 +40,12 @@ Sec-CH-Prefers-Reduced-Transparency: ### Directives - `` - - : The user agent's preference for reduced transparency. This is often taken from the underlying operating system's setting. The value of this directive can be either `no-preference` or `reduce`. ## Examples +### Using Sec-CH-Prefers-Reduced-Transparency + The client makes an initial request to the server: ```http @@ -87,6 +88,6 @@ The client will include the header in subsequent requests in the current session - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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 the {{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/sec-ch-ua-arch/index.md b/files/en-us/web/http/headers/sec-ch-ua-arch/index.md index 86a7d741c8adefd..af073d849a28811 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-arch/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-arch/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-UA-Arch {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Arch`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's underlying CPU architecture, such as ARM or x86. +The HTTP **`Sec-CH-UA-Arch`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which contains the user-agent's underlying CPU architecture, such as ARM or x86. This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download. @@ -24,7 +24,7 @@ This might be used by a server, for example, to select and offer the correct bin {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -42,6 +42,8 @@ Sec-CH-UA-Arch: ## Examples +### Using Sec-CH-UA-Arch + A server requests the `Sec-CH-UA-Arch` header by including the {{HTTPHeader("Accept-CH")}} in a response to some request from the client, using the name of the desired header as a token: ```http @@ -76,6 +78,6 @@ Note above that the [low entropy headers](/en-US/docs/Web/HTTP/Client_hints#low_ - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-bitness/index.md b/files/en-us/web/http/headers/sec-ch-ua-bitness/index.md index 777c86fbcfc6f2e..81023cc2c052c6f 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-bitness/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-bitness/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-UA-Bitness {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Bitness`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the "bitness" of the user-agent's underlying CPU architecture. +The HTTP **`Sec-CH-UA-Bitness`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which provides the "bitness" of the user-agent's underlying CPU architecture. This is the size in bits of an integer or memory address—typically 64 or 32 bits. This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download. @@ -25,7 +25,7 @@ This might be used by a server, for example, to select and offer the correct bin {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -43,7 +43,9 @@ Sec-CH-UA-Bitness: ## Examples -A server requests the `Sec-CH-UA-Bitness` header by including the {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: +### Using Sec-CH-UA-Bitness + +A server requests the `Sec-CH-UA-Bitness` header by including {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: ```http HTTP/1.1 200 OK @@ -75,6 +77,6 @@ Sec-CH-UA-Bitness: "64" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-full-version-list/index.md b/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md index cde4ae2f204e5e4..dfa8e1f0d2493e0 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md @@ -9,7 +9,15 @@ browser-compat: http.headers.Sec-CH-UA-Full-Version-List {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Full-Version-List`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's branding and full version information. +The HTTP **`Sec-CH-UA-Full-Version-List`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which provides the user-agent's branding and full version information. + +The **`Sec-CH-UA-Full-Version-List`** header provides the brand and full version information for each brand associated with the browser, in a comma-separated list. + +The header may include "fake" brands in any position and with any name. +This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity. + +> [!NOTE] +> This is similar to {{HTTPHeader("Sec-CH-UA")}}, but includes the full version number instead of the significant version number for each brand. @@ -22,25 +30,11 @@ The **`Sec-CH-UA-Full-Version-List`** [user agent client hint](/en-US/docs/Web/H - +
{{Glossary("Forbidden header name")}}yesYes (Sec- prefix)
-The **`Sec-CH-UA-Full-Version-List`** header provides the brand and full version information for each brand associated with the browser, in a comma-separated list. - -A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari. -A user agent might have several associated brands. -For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA-Full-Version-List`** header. - -The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their specific respective builds. - -The header may include "fake" brands in any position and with any name. -This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity. - -> [!NOTE] -> This is similar to {{HTTPHeader("Sec-CH-UA")}}, but includes the full version number instead of the significant version number for each brand. - ## Syntax A comma separated list of brands in the user agent brand list, and their associated full version number. @@ -58,8 +52,18 @@ Sec-CH-UA-Full-Version-List: "";v="", ... - `` - : A full version number, such as 98.0.4750.0. +#### Description + +A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari. +A user agent might have several associated brands. +For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA-Full-Version-List`** header. + +The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their specific respective builds. + ## Examples +### Using Sec-CH-UA-Full-Version-List + A server requests the `Sec-CH-UA-Full-Version-List` header by including the {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: ```http @@ -91,6 +95,6 @@ Sec-CH-UA-Platform: "Linux" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-full-version/index.md b/files/en-us/web/http/headers/sec-ch-ua-full-version/index.md index afb9c86a921b857..85106f96cfc6db2 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-full-version/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-full-version/index.md @@ -12,7 +12,7 @@ browser-compat: http.headers.Sec-CH-UA-Full-Version > [!NOTE] > This is being replaced by the {{HTTPHeader("Sec-CH-UA-Full-Version-List")}}. -The **`Sec-CH-UA-Full-Version`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's full version string. +The HTTP **`Sec-CH-UA-Full-Version`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which provides the user-agent's full version string. @@ -25,7 +25,7 @@ The **`Sec-CH-UA-Full-Version`** [user agent client hint](/en-US/docs/Web/HTTP/C - +
{{Glossary("Forbidden header name")}}yesYes (Sec- prefix)
@@ -43,6 +43,8 @@ Sec-CH-UA-Full-Version: ## Examples +### Using Sec-CH-UA-Full-Version + A server requests the `Sec-CH-UA-Full-Version` header by including the {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: ```http @@ -75,6 +77,6 @@ Sec-CH-UA-Platform: "Windows" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-mobile/index.md b/files/en-us/web/http/headers/sec-ch-ua-mobile/index.md index cd878964ef3097b..ffd70cb24d5e887 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-mobile/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-mobile/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-UA-Mobile {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Mobile`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header indicates whether the browser is on a mobile device. +The HTTP **`Sec-CH-UA-Mobile`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which indicates whether the browser is on a mobile device. It can also be used by a desktop browser to indicate a preference for a "mobile" user experience. `Sec-CH-UA-Mobile` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints). @@ -26,7 +26,7 @@ Unless blocked by a user agent permission policy, it is sent by default, without {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -45,8 +45,9 @@ Sec-CH-UA-Mobile: ## Examples -As `Sec-CH-UA-Mobile` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints) it is typically sent in all requests. +### Using Sec-CH-UA-Mobile +As `Sec-CH-UA-Mobile` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints) it is typically sent in all requests. A desktop browser would usually send requests with the following header: ```http @@ -71,6 +72,6 @@ Sec-CH-UA-Mobile: ?1 - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-model/index.md b/files/en-us/web/http/headers/sec-ch-ua-model/index.md index 01c810fb49bc7b6..b04595f4a3df0cf 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-model/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-model/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-UA-Model {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Model`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header indicates the device model on which the browser is running. +The HTTP **`Sec-CH-UA-Model`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which indicates the device model on which the browser is running. @@ -22,7 +22,7 @@ The **`Sec-CH-UA-Model`** [user agent client hint](/en-US/docs/Web/HTTP/Client_h - +
{{Glossary("Forbidden header name")}}yesYes (Sec- prefix)
@@ -40,7 +40,9 @@ Sec-CH-UA-Model: ## Examples -A server requests the `Sec-CH-UA-Model` header by including the {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: +### Using Sec-CH-UA-Model + +A server requests the `Sec-CH-UA-Model` header by including {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: ```http HTTP/1.1 200 OK @@ -73,6 +75,6 @@ Sec-CH-UA-Model: "Pixel 3 XL" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-platform-version/index.md b/files/en-us/web/http/headers/sec-ch-ua-platform-version/index.md index 8fa04f9f3516d06..3dccafdab58f050 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-platform-version/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-platform-version/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-UA-Platform-Version {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Platform-Version`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the version of the operating system on which the user agent is running. +The HTTP **`Sec-CH-UA-Platform-Version`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which provides the version of the operating system on which the user agent is running. @@ -22,7 +22,7 @@ The **`Sec-CH-UA-Platform-Version`** [user agent client hint](/en-US/docs/Web/HT - +
{{Glossary("Forbidden header name")}}yesYes (Sec- prefix)
@@ -36,14 +36,13 @@ Sec-CH-UA-Platform-Version: ### Directives - `` - - - : The version string typically contains the operating system version in a string, consisting of dot-separated major, minor and patch version numbers. - For example, `"11.0.0"` - + - : The version string typically contains the operating system version in a string, consisting of dot-separated major, minor and patch version numbers, for example `"11.0.0"`. The version string on Linux is always empty. ## Examples +### Using Sec-CH-UA-Platform-Version + A server requests the `Sec-CH-UA-Platform-Version` header by including the {{HTTPHeader("Accept-CH")}} in a _response_ to any request from the client, using the name of the desired header as a token: ```http @@ -76,6 +75,6 @@ Sec-CH-UA-Platform-Version: "10.0.0" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua-platform/index.md b/files/en-us/web/http/headers/sec-ch-ua-platform/index.md index db34d091b0ac2d5..ec8b0fd18f3527b 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-platform/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-platform/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-UA-Platform {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA-Platform`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the platform or operating system on which the user agent is running. +The HTTP **`Sec-CH-UA-Platform`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which provides the platform or operating system on which the user agent is running. For example: "Windows" or "Android". `Sec-CH-UA-Platform` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints). @@ -26,7 +26,7 @@ Unless blocked by a user agent permission policy, it is sent by default (without {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -44,8 +44,9 @@ Sec-CH-UA-Platform: ## Examples -As `Sec-CH-UA-Platform` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints) it is typically sent in all requests. +### Using Sec-CH-UA-Platform +As `Sec-CH-UA-Platform` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints) it is typically sent in all requests. A browser running on a macOS computer might add the following header to all requests. ```http @@ -64,6 +65,6 @@ Sec-CH-UA-Platform: "macOS" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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/sec-ch-ua/index.md b/files/en-us/web/http/headers/sec-ch-ua/index.md index 032a9b8030cda0d..4517d398aad1194 100644 --- a/files/en-us/web/http/headers/sec-ch-ua/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua/index.md @@ -9,7 +9,19 @@ browser-compat: http.headers.Sec-CH-UA {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The **`Sec-CH-UA`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's branding and significant version information. +The HTTP **`Sec-CH-UA`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) which provides the user-agent's branding and significant version information. + +The `Sec-CH-UA` header provides the brand and significant version for each brand associated with the browser in a comma-separated list. +The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their respective versions. + +`Sec-CH-UA` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints). +Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending {{HTTPHeader("Accept-CH")}}. + +The header may include "fake" brands in any position and with any name. +This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity. + +> [!NOTE] +> The {{HTTPHeader("Sec-CH-UA-Full-Version-List")}} header is the same as `Sec-CH-UA`, but includes the full version number rather than the significant version number for each brand. @@ -22,30 +34,11 @@ The **`Sec-CH-UA`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#u - +
{{Glossary("Forbidden header name")}}yesYes (Sec- prefix)
-The **`Sec-CH-UA`** header provides the brand and significant version for each brand associated with the browser in a comma-separated list. - -A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari. -A user agent might have several associated brands. -For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA`** header. - -The _significant version_ is the "marketing" version identifier that is used to distinguish between major releases of the brand. -For example a Chromium build with _full version number_ "96.0.4664.45" has a significant version number of "96". - -The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their respective versions. - -`Sec-CH-UA` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints). -Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending {{HTTPHeader("Accept-CH")}}. - -The header may include "fake" brands in any position and with any name. -This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity. - -> **Note:** {{HTTPHeader("Sec-CH-UA-Full-Version-List")}} is the same as **`Sec-CH-UA`**, but includes the full version number rather than the significant version number for each brand. - ## Syntax A comma separated list of brands in the user agent brand list, and their associated significant version number. @@ -62,8 +55,19 @@ Sec-CH-UA: "";v="", ... - `` - : The "marketing" version number associated with distinguishable web-exposed features. +#### Description + +A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari. +A user agent might have several associated brands. +For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the `Sec-CH-UA` header. + +The _significant version_ is the "marketing" version identifier that is used to distinguish between major releases of the brand. +For example a Chromium build with _full version number_ "96.0.4664.45" has a significant version number of "96". + ## Examples +### Different Sec-CH-UA brands + `Sec-CH-UA` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints). Unless explicitly blocked by a user agent policy, it will be sent in all requests (without the server having to opt in by sending {{HTTPHeader("Accept-CH")}}). @@ -99,6 +103,6 @@ Sec-CH-UA: "Opera";v="81", " Not;A Brand";v="99", "Chromium";v="95" - [Client hints](/en-US/docs/Web/HTTP/Client_hints) - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API) -- [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) - {{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")}} +- [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/sec-fetch-dest/index.md b/files/en-us/web/http/headers/sec-fetch-dest/index.md index 44e089eff457597..c280f6f0ccb960f 100644 --- a/files/en-us/web/http/headers/sec-fetch-dest/index.md +++ b/files/en-us/web/http/headers/sec-fetch-dest/index.md @@ -7,7 +7,8 @@ browser-compat: http.headers.Sec-Fetch-Dest {{HTTPSidebar}} -The **`Sec-Fetch-Dest`** {{Glossary("Fetch metadata request header", "fetch metadata request header")}} indicates the request's _destination_. That is the initiator of the original fetch request, which is where (and how) the fetched data will be used. +The HTTP **`Sec-Fetch-Dest`** {{Glossary("fetch metadata request header")}} indicates the request's _destination_. +That is the initiator of the original fetch request, which is where (and how) the fetched data will be used. This allows servers to determine whether to service a request based on whether it is appropriate for how it is _expected_ to be used. For example, a request with an `audio` destination should request audio data, not some other type of resource (for example, a document that includes sensitive user information). @@ -19,13 +20,13 @@ This allows servers to determine whether to service a request based on whether i {{Glossary("Forbidden header name")}} - yes (prefix Sec-) + Yes (Sec- prefix) {{Glossary("CORS-safelisted request header")}} - no + No @@ -114,6 +115,8 @@ Servers should ignore this header if it contains any other value. ## Examples +### Using Sec-Fetch-Dest + A cross-site request generated by an {{HTMLElement("img")}} element would result in a request with the following HTTP request headers (note that the destination is `image`): ```http @@ -132,11 +135,6 @@ Sec-Fetch-Site: cross-site ## See also -- Related headers - - - {{HTTPHeader("Sec-Fetch-Mode")}} - - {{HTTPHeader("Sec-Fetch-Site")}} - - {{HTTPHeader("Sec-Fetch-User")}} - +- {{HTTPHeader("Sec-Fetch-Mode")}}, {{HTTPHeader("Sec-Fetch-Site")}}, {{HTTPHeader("Sec-Fetch-User")}} fetch metadata request headers - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev) - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com) diff --git a/files/en-us/web/http/headers/sec-fetch-mode/index.md b/files/en-us/web/http/headers/sec-fetch-mode/index.md index d000e32350533a7..911b1566998f9cd 100644 --- a/files/en-us/web/http/headers/sec-fetch-mode/index.md +++ b/files/en-us/web/http/headers/sec-fetch-mode/index.md @@ -7,9 +7,10 @@ browser-compat: http.headers.Sec-Fetch-Mode {{HTTPSidebar}} -The **`Sec-Fetch-Mode`** {{Glossary("Fetch metadata request header", "fetch metadata request header")}} indicates the [mode](/en-US/docs/Web/API/Request/mode) of the request. +The HTTP **`Sec-Fetch-Mode`** {{Glossary("fetch metadata request header")}} indicates the [mode](/en-US/docs/Web/API/Request/mode) of the request. -Broadly speaking, this allows a server to distinguish between: requests originating from a user navigating between HTML pages, and requests to load images and other resources. For example, this header would contain `navigate` for top level navigation requests, while `no-cors` is used for loading an image. +Broadly speaking, this allows a server to distinguish between requests originating from a user navigating between HTML pages, and requests to load images and other resources. +For example, this header would contain `navigate` for top level navigation requests, while `no-cors` is used for loading an image. @@ -19,13 +20,13 @@ Broadly speaking, this allows a server to distinguish between: requests originat - + - +
{{Glossary("Forbidden header name")}}yes (prefix Sec-)Yes (Sec- prefix)
{{Glossary("CORS-safelisted request header")}} noNo
@@ -60,6 +61,8 @@ Servers should ignore this header if it contains any other value. ## Examples +### Using Sec-Fetch-Mode + If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers (note that the mode is `navigate`): ```http @@ -87,11 +90,6 @@ Sec-Fetch-Site: cross-site ## See also -- Related headers - - - {{HTTPHeader("Sec-Fetch-Dest")}} - - {{HTTPHeader("Sec-Fetch-Site")}} - - {{HTTPHeader("Sec-Fetch-User")}} - +- {{HTTPHeader("Sec-Fetch-Dest")}}, {{HTTPHeader("Sec-Fetch-Site")}}, {{HTTPHeader("Sec-Fetch-User")}} fetch metadata request headers - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev) - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com) diff --git a/files/en-us/web/http/headers/sec-fetch-site/index.md b/files/en-us/web/http/headers/sec-fetch-site/index.md index 1f12ad5c3a72623..b588a5e634a95eb 100644 --- a/files/en-us/web/http/headers/sec-fetch-site/index.md +++ b/files/en-us/web/http/headers/sec-fetch-site/index.md @@ -7,11 +7,11 @@ browser-compat: http.headers.Sec-Fetch-Site {{HTTPSidebar}} -The **`Sec-Fetch-Site`** {{Glossary("Fetch metadata request header", "fetch metadata request header")}} indicates the relationship between a request initiator's origin and the origin of the requested resource. +The HTTP **`Sec-Fetch-Site`** {{Glossary("fetch metadata request header")}} indicates the relationship between a request initiator's origin and the origin of the requested resource. In other words, this header tells a server whether a request for a resource is coming from the same origin, the same site, a different site, or is a "user initiated" request. The server can then use this information to decide if the request should be allowed. -Same-origin requests would usually be allowed by default, but what happens for requests from other origins may further depend on what resource is being requested, or information in other {{Glossary("Fetch metadata request header","Fetch metadata request headers")}}. By default, requests that are not accepted should be rejected with a {{HTTPStatus("403")}} response code. +Same-origin requests would usually be allowed by default, but what happens for requests from other origins may further depend on what resource is being requested, or information in another {{Glossary("fetch metadata request header")}}. By default, requests that are not accepted should be rejected with a {{HTTPStatus("403")}} response code. @@ -21,13 +21,13 @@ Same-origin requests would usually be allowed by default, but what happens for r - + - +
{{Glossary("Forbidden header name")}}yes (prefix Sec-)Yes (Sec- prefix)
{{Glossary("CORS-safelisted request header")}} noNo
@@ -83,11 +83,6 @@ Sec-Fetch-Site: cross-site ## See also -- Related headers - - - {{HTTPHeader("Sec-Fetch-Mode")}} - - {{HTTPHeader("Sec-Fetch-User")}} - - {{HTTPHeader("Sec-Fetch-Dest")}} - +- {{HTTPHeader("Sec-Fetch-Mode")}}, {{HTTPHeader("Sec-Fetch-User")}}, {{HTTPHeader("Sec-Fetch-Dest")}} fetch metadata request headers - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev) - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com) diff --git a/files/en-us/web/http/headers/sec-fetch-user/index.md b/files/en-us/web/http/headers/sec-fetch-user/index.md index d130e502e7f6108..4e294e55e1dd702 100644 --- a/files/en-us/web/http/headers/sec-fetch-user/index.md +++ b/files/en-us/web/http/headers/sec-fetch-user/index.md @@ -7,7 +7,7 @@ browser-compat: http.headers.Sec-Fetch-User {{HTTPSidebar}} -The **`Sec-Fetch-User`** {{Glossary("Fetch metadata request header", "fetch metadata request header")}} is only sent for requests initiated by user activation, and its value will always be `?1`. +The HTTP **`Sec-Fetch-User`** {{Glossary("fetch metadata request header")}} is sent for requests initiated by user activation, and its value is always `?1`. A server can use this header to identify whether a navigation request from a document, iframe, etc., was originated by the user. @@ -19,13 +19,13 @@ A server can use this header to identify whether a navigation request from a doc {{Glossary("Forbidden header name")}} - yes (prefix Sec-) + Yes (Sec- prefix) {{Glossary("CORS-safelisted request header")}} - no + No @@ -42,6 +42,8 @@ The value will always be `?1`. When a request is triggered by something other th ## Examples +### Using Sec-Fetch-User + If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers: ```http @@ -61,11 +63,6 @@ Sec-Fetch-User: ?1 ## See also -- Related headers - - - {{HTTPHeader("Sec-Fetch-Dest")}} - - {{HTTPHeader("Sec-Fetch-Mode")}} - - {{HTTPHeader("Sec-Fetch-Site")}} - +- {{HTTPHeader("Sec-Fetch-Dest")}}, {{HTTPHeader("Sec-Fetch-Mode")}}, {{HTTPHeader("Sec-Fetch-Site")}} fetch metadata request headers - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev) - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com) diff --git a/files/en-us/web/http/headers/sec-gpc/index.md b/files/en-us/web/http/headers/sec-gpc/index.md index 1c933d9ca20d098..285d1e131f5b160 100644 --- a/files/en-us/web/http/headers/sec-gpc/index.md +++ b/files/en-us/web/http/headers/sec-gpc/index.md @@ -11,10 +11,9 @@ spec-urls: https://privacycg.github.io/gpc-spec/ {{HTTPSidebar}}{{SeeCompatTable}}{{non-standard_header}} -The **`Sec-GPC`** ([**G**lobal **P**rivacy **C**ontrol](https://globalprivacycontrol.org/)) request header indicates whether the user consents to a website or service selling or sharing their personal information with third parties. +The HTTP **`Sec-GPC`** {{Glossary("request header")}} is part of the [Global Privacy Control](https://globalprivacycontrol.org/) (GPC) mechanism to indicate whether the user consents to a website or service selling or sharing their personal information with third parties. The specification does not define how the user can withdraw or grant consent for website. -Where possible the mechanism will be indicated in the [browser compatibility](#browser_compatibility) section below. @@ -24,7 +23,7 @@ Where possible the mechanism will be indicated in the [browser compatibility](#b - +
{{Glossary("Forbidden header name")}}yesYes (Sec- prefix)
@@ -32,14 +31,14 @@ Where possible the mechanism will be indicated in the [browser compatibility](#b ## Syntax ```http -Sec-GPC: 1 +Sec-GPC: ``` ## Directives -The `Sec-GPC` is header is sent with a value of `1` if the user has indicated that they prefer their information not be shared with, or sold to, third parties. - -Otherwise, the header is not sent, which indicates that either the user has not made a decision or the user is okay with their information being shared with or sold to third parties. +- `` + - : A value of `1` means the user has indicated that they prefer their information not be shared with, or sold to, third parties. + Otherwise, the header is not sent, which indicates that either the user has not made a decision or the user is okay with their information being shared with or sold to third parties. ## Examples diff --git a/files/en-us/web/http/headers/sec-purpose/index.md b/files/en-us/web/http/headers/sec-purpose/index.md index f7ba76d25d36374..88dfeddc7964b37 100644 --- a/files/en-us/web/http/headers/sec-purpose/index.md +++ b/files/en-us/web/http/headers/sec-purpose/index.md @@ -7,7 +7,7 @@ browser-compat: http.headers.Sec-Purpose {{HTTPSidebar}} -The **`Sec-Purpose`** {{Glossary("Fetch metadata request header", "fetch metadata request header")}} indicates the purpose for which the requested resource will be used, when that purpose is something other than immediate use by the user-agent. +The HTTP **`Sec-Purpose`** {{Glossary("fetch metadata request header")}} indicates the purpose for which the requested resource will be used, when that purpose is something other than immediate use by the user-agent. The only purpose that is currently defined is `prefetch`, which indicates that the resource is being requested in anticipation that it will be needed by a page that is likely to be navigated to in the near future, such as a page linked in search results or a link that a user has hovered over. The server can use this knowledge to: adjust the caching expiry for the request, disallow the request, or perhaps to treat it differently when counting page visits. @@ -23,13 +23,13 @@ Note that if this header is set then a {{HTTPHeader("Sec-Fetch-Dest")}} header i {{Glossary("Forbidden header name")}} - yes (prefix Sec-) + Yes (Sec- prefix) {{Glossary("CORS-safelisted request header")}} - no + No @@ -87,5 +87,6 @@ Cache-Control: no-cache ## See also +- {{HTTPHeader("Sec-Fetch-Dest")}}, {{HTTPHeader("Sec-Fetch-Mode")}}, {{HTTPHeader("Sec-Fetch-Site")}}, {{HTTPHeader("Sec-Fetch-User")}} fetch metadata request headers - {{Glossary("Prefetch")}} (Glossary) - [``](/en-US/docs/Web/HTML/Element/link) element with attribute [`rel="prefetch"`](/en-US/docs/Web/HTML/Attributes/rel/prefetch) diff --git a/files/en-us/web/http/headers/sec-websocket-accept/index.md b/files/en-us/web/http/headers/sec-websocket-accept/index.md index 53f4e86bb5ec2ba..843f4db9290adac 100644 --- a/files/en-us/web/http/headers/sec-websocket-accept/index.md +++ b/files/en-us/web/http/headers/sec-websocket-accept/index.md @@ -8,7 +8,7 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc6455#section-11.3.3 {{HTTPSidebar}} -The **Sec-WebSocket-Accept** HTTP {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate that the server is willing to upgrade to a WebSocket connection. +The HTTP **Sec-WebSocket-Accept** {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate that the server is willing to upgrade to a WebSocket connection. This header must appear no more than once in the response, and has a directive value that is calculated from the {{HTTPHeader("Sec-WebSocket-Key")}} request header sent in the corresponding request. @@ -20,7 +20,7 @@ This header must appear no more than once in the response, and has a directive v {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -33,15 +33,17 @@ Sec-WebSocket-Accept: ## Directives -- \ +- `` - : If a {{HTTPHeader("Sec-WebSocket-Key")}} header was provided, the value of this header is computed by taking the value of the key, concatenating the string `258EAFA5-E914-47DA-95CA-C5AB0DC85B11`, and taking the [SHA-1](https://en.wikipedia.org/wiki/SHA-1) hash of that concatenated string — resulting in a 20-byte value. That value is then [base64](/en-US/docs/Glossary/Base64) encoded to obtain the value of this property. ## Examples +### WebSocket opening handshake + The client will initiate a WebSocket handshake with a request like the following. -Note that this starts as an HTTP `GET` request (HTTP/1.1 or later) and includes the {{httpheader("Upgrade")}} header indicating the intent to upgrade to a web socket. -It also includes `Sec-WebSocket-Key`, which is used in the calculation of `Sec-WebSocket-Accept` to confirm the intent to upgrade the connection to a web socket. +Note that this starts as an HTTP `GET` request (HTTP/1.1 or later) and includes the {{httpheader("Upgrade")}} header indicating the intent to upgrade to a WebSocket connection. +It also includes `Sec-WebSocket-Key`, which is used in the calculation of `Sec-WebSocket-Accept` to confirm the intent to upgrade the connection to a WebSocket connection. ```http GET /chat HTTP/1.1 @@ -52,7 +54,7 @@ Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 ``` -The response from the server should include the `Sec-WebSocket-Accept` header with a value that is calculated from the `Sec-WebSocket-Key` header in the request, and confirms the intent to upgrade the connection to a web socket: +The response from the server should include the `Sec-WebSocket-Accept` header with a value that is calculated from the `Sec-WebSocket-Key` header in the request, and confirms the intent to upgrade the connection to a WebSocket connection: ```http HTTP/1.1 101 Switching Protocols diff --git a/files/en-us/web/http/headers/sec-websocket-extensions/index.md b/files/en-us/web/http/headers/sec-websocket-extensions/index.md index 6274ae57bc10fea..e5465b951441675 100644 --- a/files/en-us/web/http/headers/sec-websocket-extensions/index.md +++ b/files/en-us/web/http/headers/sec-websocket-extensions/index.md @@ -8,7 +8,7 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc6455#section-11.3.2 {{HTTPSidebar}} -The **Sec-WebSocket-Extensions** HTTP {{glossary("request header", "request")}} and {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a protocol extension used by the client and server. +The HTTP **Sec-WebSocket-Extensions** {{glossary("request header", "request")}} and {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a protocol extension used by the client and server. In a request the header specifies one or more extensions that the web application would like to use, in order of preference. These can be added as in multiple headers, or as comma separate values added to a single header. @@ -26,7 +26,7 @@ The request header is automatically added by the browser based on its own capabi {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -54,6 +54,8 @@ Sec-WebSocket-Extensions: ## Examples +### WebSocket opening handshake + The HTTP request below shows the opening handshake where a client supports the `permessage-deflate` and `client_max_window_bits` extensions. ```http diff --git a/files/en-us/web/http/headers/sec-websocket-key/index.md b/files/en-us/web/http/headers/sec-websocket-key/index.md index 1c617c14c6cd3f6..99b6201c96a2935 100644 --- a/files/en-us/web/http/headers/sec-websocket-key/index.md +++ b/files/en-us/web/http/headers/sec-websocket-key/index.md @@ -8,7 +8,7 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc6455#section-11.3.1 {{HTTPSidebar}} -The **Sec-WebSocket-Key** HTTP {{glossary("request header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to allow a client (user agent) to confirm that it "really wants" to request that an HTTP client is upgraded to become a WebSocket. +The HTTP **Sec-WebSocket-Key** {{glossary("request header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to allow a client (user agent) to confirm that it "really wants" to request that an HTTP client is upgraded to become a WebSocket. The value of the key is computed using an algorithm defined in the WebSocket specification, so this _does not provide security_. Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection. @@ -26,7 +26,7 @@ The user agent can then validate this before this before confirming the connecti {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -39,15 +39,17 @@ Sec-WebSocket-Key: ## Directives -- \ +- `` - : The key for this request to upgrade. This is a randomly selected 16-byte nonce that has been base64-encoded and isomorphic encoded. The user agent adds this when initiating the WebSocket connection. ## Examples +### WebSocket opening handshake + The client will initiate a WebSocket handshake with a request like the following. -Note that this starts as an HTTP `GET` request (HTTP/1.1 or later), in addition to `Sec-WebSocket-Key`, the request includes the {{httpheader("Upgrade")}} header, indicating the intent to upgrade from HTTP to a web socket. +Note that this starts as an HTTP `GET` request (HTTP/1.1 or later), in addition to `Sec-WebSocket-Key`, the request includes the {{httpheader("Upgrade")}} header, indicating the intent to upgrade from HTTP to a WebSocket connection. ```http GET /chat HTTP/1.1 @@ -58,7 +60,7 @@ Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 ``` -The response from the server should include the `Sec-WebSocket-Accept` header with a value that is calculated from the `Sec-WebSocket-Key` header in the request, and confirms the intent to upgrade the connection to a web socket: +The response from the server should include the `Sec-WebSocket-Accept` header with a value that is calculated from the `Sec-WebSocket-Key` header in the request, and confirms the intent to upgrade the connection to a WebSocket connection: ```http HTTP/1.1 101 Switching Protocols diff --git a/files/en-us/web/http/headers/sec-websocket-protocol/index.md b/files/en-us/web/http/headers/sec-websocket-protocol/index.md index 59ab9e025cd6007..7a09df47afdffb9 100644 --- a/files/en-us/web/http/headers/sec-websocket-protocol/index.md +++ b/files/en-us/web/http/headers/sec-websocket-protocol/index.md @@ -8,7 +8,7 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc6455#section-11.3.4 {{HTTPSidebar}} -The **`Sec-WebSocket-Protocol`** HTTP {{glossary("request header", "request")}} and {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a [sub-protocol](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#subprotocols) to use in the communication. +The HTTP **`Sec-WebSocket-Protocol`** {{glossary("request header", "request")}} and {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a [sub-protocol](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#subprotocols) to use in the communication. This can be a well understood protocol, such as SOAP or WAMP, or a custom protocol understood by the client and server. In a request the header specifies one or more WebSocket sub-protocols that the web application would like to use, in order of preference. @@ -28,7 +28,7 @@ The sub-protocol selected by the server is made available to the web application {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -55,6 +55,8 @@ Sec-WebSocket-Protocol: ## Examples +### WebSocket opening handshake + The sub-protocol is specified in the original WebSocket [handshake request](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake). The request below shows that the client prefers `soap`, but also supports `wamp`. diff --git a/files/en-us/web/http/headers/sec-websocket-version/index.md b/files/en-us/web/http/headers/sec-websocket-version/index.md index af38edf4da19869..cf78bccdea7ca73 100644 --- a/files/en-us/web/http/headers/sec-websocket-version/index.md +++ b/files/en-us/web/http/headers/sec-websocket-version/index.md @@ -8,7 +8,7 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc6455#section-11.3.5 {{HTTPSidebar}} -The **Sec-WebSocket-Version** HTTP {{glossary("request header", "request")}} and {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate the WebSocket protocol supported by the client, and the protocol versions supported by the server if it does _not_ support the version specified in the request. +The HTTP **Sec-WebSocket-Version** {{glossary("request header", "request")}} and {{glossary("response header")}} is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate the WebSocket protocol supported by the client, and the protocol versions supported by the server if it does _not_ support the version specified in the request. The header can only appear once in a request, and specifies the WebSocket version that web application is using. The current version of the protocol at time of writing is 13. @@ -29,7 +29,7 @@ The header should not be sent in responses if the server understands the version {{Glossary("Forbidden header name")}} - yes + Yes (Sec- prefix) @@ -51,17 +51,17 @@ Sec-WebSocket-Version: ## Directives - `` - - : The WebSocket protocol version the client wishes to use when communicating with the server. This number should be the most recent version possible listed in the [IANA WebSocket Version Number Registry](https://www.iana.org/assignments/websocket/websocket.xml#version-number). The most recent final version of the WebSocket protocol is version 13. - - `` - : On error, a comma-delineated list of the WebSocket protocol versions supported by the server. The header is not sent in responses if `` is supported. ## Examples +### WebSocket opening handshake + The version supported by the client is specified in the original `WebSocket` [handshake request](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake). For the current protocol, the version is "13", as shown below. From c18a38091024766d3d20a4305b15258e9e03882c Mon Sep 17 00:00:00 2001 From: Brian Thomas Smith Date: Mon, 18 Nov 2024 16:58:47 +0100 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Hamish Willee --- files/en-us/web/http/headers/repr-digest/index.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) 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 5539721d286baca..3f290ba56462c08 100644 --- a/files/en-us/web/http/headers/repr-digest/index.md +++ b/files/en-us/web/http/headers/repr-digest/index.md @@ -8,7 +8,8 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc9530 {{HTTPSidebar}} The HTTP **`Repr-Digest`** {{Glossary("Request header", "request")}} and {{Glossary("Response header", "response header")}} provides a {{Glossary("digest")}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. -Variants in {{HTTPHeader("Content-Encoding")}} and {{HTTPHeader("Content-Range")}}, for example, have no influence on the `Repr-Digest` digests, as opposed to the {{HTTPHeader("Content-Digest")}}, which does vary based on such changes to message content. + +The representation digest applies to the whole resource rather than the encoding or chunking of the messages that are used to send it. This differs from {HTTPHeader("Content-Digest")}} which applies to the content of a particular message, and is therefore is affected by the {{HTTPHeader("Content-Encoding")}} and {{HTTPHeader("Content-Range")}} of each message. Furthermore, [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representations which results in different representation digests. @@ -46,14 +47,15 @@ Repr-Digest: =,= ### Usage notes -Usage of digest algorithms which are considered insecure is discouraged as collisions can realistically be forced, rendering the digest's usefulness weak. +Usage of insecure digest algorithms is discouraged as collisions can realistically be forced, rendering the digest's usefulness weak. Unless working with legacy systems (which is unlikely since most will expect the legacy {{HTTPHeader("Digest")}} header and not understand this specification), consider omitting a `Repr-Digest` instead of including one with an insecure digest algorithm. ## Examples ### HTTP response where `Repr-Digest` and `Content-Digest` coincide -An HTTP server may send content octets equivalent to the selected representation's octets. +An HTTP server may send the whole representation unencoded in a single message. +In this case, `Repr-Digest` and `Content-Digest` have equal values for the same digest algorithms: In this case, `Repr-Digest` and `Content-Digest` have equal values for the same digest algorithms: ```http @@ -72,7 +74,8 @@ Content-Range: 0-38053/38054 ### HTTP responses where `Repr-Digest` and `Content-Digest` diverge -A static file server may compress an HTML page, meaning the {{HTTPHeader("Content-Digest")}} will have a different value to the `Repr-Digest` header in a response, given the same digest algorithm: +A server may compress the content for sending. +In this case {{HTTPHeader("Content-Digest")}} will depend on the {{HTTPHeader("Content-Encoding")}}, and will therefore have a different value to the `Repr-Digest` header in a response: ```http … From e996e9a338a7a213fd54d5119d951b02543dc249 Mon Sep 17 00:00:00 2001 From: Brian Thomas Smith Date: Mon, 18 Nov 2024 17:37:30 +0100 Subject: [PATCH 3/3] chore(http): Changes following reviewer feedback --- .../web/http/headers/repr-digest/index.md | 18 +++++++++--------- .../en-us/web/http/headers/save-data/index.md | 10 ++++------ .../index.md | 2 +- .../sec-ch-ua-full-version-list/index.md | 6 +++--- .../en-us/web/http/headers/sec-ch-ua/index.md | 4 ++-- 5 files changed, 19 insertions(+), 21 deletions(-) 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 3f290ba56462c08..e71299d244c113c 100644 --- a/files/en-us/web/http/headers/repr-digest/index.md +++ b/files/en-us/web/http/headers/repr-digest/index.md @@ -7,10 +7,13 @@ spec-urls: https://datatracker.ietf.org/doc/html/rfc9530 {{HTTPSidebar}} -The HTTP **`Repr-Digest`** {{Glossary("Request header", "request")}} and {{Glossary("Response header", "response header")}} provides a {{Glossary("digest")}} of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. +The HTTP **`Repr-Digest`** {{Glossary("Request header", "request")}} and {{Glossary("Response header", "response header")}} provides a {{Glossary("digest")}} of the selected representation of the target resource. -The representation digest applies to the whole resource rather than the encoding or chunking of the messages that are used to send it. This differs from {HTTPHeader("Content-Digest")}} which applies to the content of a particular message, and is therefore is affected by the {{HTTPHeader("Content-Encoding")}} and {{HTTPHeader("Content-Range")}} of each message. -Furthermore, [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representations which results in different representation digests. +The _selected representation_ is the specific format of a resource chosen through [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation). +Details about this representation can be determined from the response's {{Glossary("Representation header", "representation headers")}}, such as {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Type")}}, and {{HTTPHeader("Content-Encoding")}}. + +The representation digest applies to the whole resource rather than the encoding or chunking of the messages that are used to send it. +This differs from {{HTTPHeader("Content-Digest")}} which applies to the content of a particular message, and is therefore is affected by the {{HTTPHeader("Content-Encoding")}} and {{HTTPHeader("Content-Range")}} of each message.
@@ -42,11 +45,9 @@ Repr-Digest: =,= The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`. - `` - : The digest in bytes of the representation using the ``. - The choice of digest algorithm also determines the encoding to use: `sha-512` and `sha-256` use base64 encoding, while some legacy digest algorithms such as `unixsum` use a decimal integer. + The choice of digest algorithm also determines the encoding to use: `sha-512` and `sha-256` use {{Glossary("base64")}} encoding, while some legacy digest algorithms such as `unixsum` use a decimal integer. In contrast to earlier drafts of the specification, the standard-base64-encoded digest bytes are wrapped in colons (`:`, ASCII 0x3A) as part of the [dictionary syntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences). -### Usage notes - Usage of insecure digest algorithms is discouraged as collisions can realistically be forced, rendering the digest's usefulness weak. Unless working with legacy systems (which is unlikely since most will expect the legacy {{HTTPHeader("Digest")}} header and not understand this specification), consider omitting a `Repr-Digest` instead of including one with an insecure digest algorithm. @@ -56,7 +57,6 @@ Unless working with legacy systems (which is unlikely since most will expect the An HTTP server may send the whole representation unencoded in a single message. In this case, `Repr-Digest` and `Content-Digest` have equal values for the same digest algorithms: -In this case, `Repr-Digest` and `Content-Digest` have equal values for the same digest algorithms: ```http … @@ -64,7 +64,7 @@ Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=: Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=: … Content-Type: text/yaml -Content-Encoding: identity +Content-Encoding: br Content-Length: 38054 Content-Range: 0-38053/38054 … @@ -97,7 +97,7 @@ Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U5 Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=: … Content-Type: text/html; charset=utf-8 -Content-Encoding: deflate, deflate, deflate +Content-Encoding: zstd … [message body] diff --git a/files/en-us/web/http/headers/save-data/index.md b/files/en-us/web/http/headers/save-data/index.md index bca0da1cf54fe23..76f8757dde360f3 100644 --- a/files/en-us/web/http/headers/save-data/index.md +++ b/files/en-us/web/http/headers/save-data/index.md @@ -15,6 +15,9 @@ This could be for reasons such as high transfer costs, slow connection speeds, e `Save-Data` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints), and hence may be sent by the client even if not requested by the server using an {{HTTPHeader("Accept-CH")}} response header. Further, it should be used to reduce data sent to the client irrespective of the values of other client hints that indicate network capability, like {{HTTPHeader("Downlink")}} and {{HTTPHeader("RTT")}}. +A value of `On` indicates explicit user opt-in into a reduced data usage mode on the client. +When communicated to origins, this allows them to deliver alternative content to reduce the data downloaded such as smaller image and video resources, different markup and styling, disabled polling and automatic updates, and so on. + > [!NOTE] > Disabling HTTP/2 Server Push ({{RFC("7540", "Server Push", "8.2")}}) may reduce data downloads. > Note that this feature is no longer supported by default in most major browser engines. @@ -53,11 +56,6 @@ Save-Data: - : A value indicating whether the client wants to opt in to reduced data usage mode. `on` indicates yes, while `off` (the default) indicates no. -### Description - -A value of `On` indicates explicit user opt-in into a reduced data usage mode on the client. -When communicated to origins, this allows them to deliver alternative content to reduce the data downloaded such as smaller image and video resources, different markup and styling, disabled polling and automatic updates, and so on. - ## Examples ### Using `Save-Data: on` @@ -115,7 +113,7 @@ Content-Type: image/jpeg ## See also -- CSS @media feature [`prefers-reduced-data`](/en-US/docs/Web/CSS/@media/prefers-reduced-data) {{experimental_inline}} +- CSS `@media` feature [`prefers-reduced-data`](/en-US/docs/Web/CSS/@media/prefers-reduced-data) {{experimental_inline}} - {{HTTPHeader("Vary")}} header which indicates that the content served varies depending on the value of `Save-Data` (see [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary)) - {{domxref("NetworkInformation.saveData")}} - [Help Your Users `Save-Data`](https://css-tricks.com/help-users-save-data/) on css-tricks.com diff --git a/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md b/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md index e3e6b4963a09bdf..485065b1e5fe1e9 100644 --- a/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md +++ b/files/en-us/web/http/headers/sec-ch-prefers-reduced-transparency/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Sec-CH-Prefers-Reduced-Transparency {{HTTPSidebar}}{{SeeCompatTable}}{{SecureContext_Header}} -The HTTP **`Sec-CH-Prefers-Reduced-Transparency`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) which indicates the user agent's preference for reduced transparency. +The HTTP **`Sec-CH-Prefers-Reduced-Transparency`** {{Glossary("request header")}} is a [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) that indicates the user agent's preference for reduced transparency. If a server signals to a client via the {{httpheader("Accept-CH")}} header that it accepts `Sec-CH-Prefers-Reduced-Transparency`, the client can then respond with this header to indicate the user's preference for reduced transparency. The server can send the client appropriately adapted content — for example, CSS or images — to reduce the transparency of the content. diff --git a/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md b/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md index dfa8e1f0d2493e0..7980e1a2598c134 100644 --- a/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua-full-version-list/index.md @@ -52,13 +52,13 @@ Sec-CH-UA-Full-Version-List: "";v="", ... - `` - : A full version number, such as 98.0.4750.0. -#### Description +## Description A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari. A user agent might have several associated brands. -For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA-Full-Version-List`** header. +For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the `Sec-CH-UA-Full-Version-List` header. -The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their specific respective builds. +The header allows the server to customize its response based on both shared brands and on particular customizations in their specific respective builds. ## Examples diff --git a/files/en-us/web/http/headers/sec-ch-ua/index.md b/files/en-us/web/http/headers/sec-ch-ua/index.md index 4517d398aad1194..024647e687f5c8a 100644 --- a/files/en-us/web/http/headers/sec-ch-ua/index.md +++ b/files/en-us/web/http/headers/sec-ch-ua/index.md @@ -45,7 +45,7 @@ A comma separated list of brands in the user agent brand list, and their associa The syntax for a single entry has the following format: ```http -Sec-CH-UA: "";v="", ... +Sec-CH-UA: "";v="", … ``` ### Directives @@ -55,7 +55,7 @@ Sec-CH-UA: "";v="", ... - `` - : The "marketing" version number associated with distinguishable web-exposed features. -#### Description +## Description A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari. A user agent might have several associated brands.