From 0d07450e212545498ff7dc9a0a4aae45a537904d Mon Sep 17 00:00:00 2001 From: Brian Thomas Smith Date: Tue, 5 Nov 2024 09:55:07 +0100 Subject: [PATCH 1/2] fix(http): Accept-Encoding can appear in both requests and responses --- .vscode/dictionaries/terms-abbreviations.txt | 2 ++ files/en-us/web/http/headers/accept-encoding/index.md | 10 ++++++---- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/.vscode/dictionaries/terms-abbreviations.txt b/.vscode/dictionaries/terms-abbreviations.txt index dd9c1333dd094f0..defc2b74bdd8224 100644 --- a/.vscode/dictionaries/terms-abbreviations.txt +++ b/.vscode/dictionaries/terms-abbreviations.txt @@ -83,6 +83,7 @@ BMFF bootup botmaster BPTC +Brotli browserless BSAC bytestream @@ -880,5 +881,6 @@ yearless Zalgo zoomable ZQSD +Zstandard ZWNBSP ZWSP diff --git a/files/en-us/web/http/headers/accept-encoding/index.md b/files/en-us/web/http/headers/accept-encoding/index.md index 563d6464a6a6b0b..ec02ca832802a78 100644 --- a/files/en-us/web/http/headers/accept-encoding/index.md +++ b/files/en-us/web/http/headers/accept-encoding/index.md @@ -7,7 +7,9 @@ browser-compat: http.headers.Accept-Encoding {{HTTPSidebar}} -The HTTP **`Accept-Encoding`** {{Glossary("request header")}} indicates the content encoding (usually a compression algorithm) that the client can understand. The server uses [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) to select one of the proposals and informs the client of that choice with the {{HTTPHeader("Content-Encoding")}} response header. +The HTTP **`Accept-Encoding`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates the content encoding (usually a compression algorithm) that the recipient can understand. +In requests, the server uses [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) to select one of the encoding proposals from the client and informs the client of that choice with the {{HTTPHeader("Content-Encoding")}} response header. +In responses, it provides information about which encodings are preferred in the content of a subsequent request to the same resource. Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the `identity` value is also acceptable. This happens in two common cases: @@ -26,7 +28,7 @@ As long as the `identity;q=0` or `*;q=0` directives do not explicitly forbid the Header type - {{Glossary("Request header")}} + {{Glossary("Request header")}}, {{Glossary("Response header")}} {{Glossary("Forbidden header name")}} @@ -64,7 +66,7 @@ Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5 - : A compression format that uses the [Zstandard](https://en.wikipedia.org/wiki/Zstd) algorithm. - `identity` - : Indicates the identity function (that is, without modification or compression). This value is always considered as acceptable, even if omitted. -- `*` +- `*` (wildcard) - : Matches any content encoding not already listed in the header. This is the default value if the header is not present. This directive does not suggest that any algorithm is supported but indicates that no preference is expressed. - `;q=` (qvalues weighting) - : Any value is placed in an order of preference expressed using a relative [quality value](/en-US/docs/Glossary/Quality_values) called _weight_. @@ -83,7 +85,7 @@ Accept-Encoding: gzip, deflate, br, zstd ### Weighted Accept-Encoding values -The following request header shows `Accept-Encoding` preferences using a quality value between `0` (lowest priority) and `1` (highest-priority). +The following header shows `Accept-Encoding` preferences using a quality value between `0` (lowest priority) and `1` (highest-priority). Brotli compression is weighted at `1.0`, making `br` the client's first choice, followed by `gzip` at `0.8` priority, and then any other content encoding at `0.1`: ```http From 91277bc22de4e05e76a16a190389768cb54e69d5 Mon Sep 17 00:00:00 2001 From: Brian Thomas Smith Date: Wed, 13 Nov 2024 11:02:31 +0100 Subject: [PATCH 2/2] Update files/en-us/web/http/headers/accept-encoding/index.md Co-authored-by: Hamish Willee --- files/en-us/web/http/headers/accept-encoding/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/http/headers/accept-encoding/index.md b/files/en-us/web/http/headers/accept-encoding/index.md index ec02ca832802a78..7851ac43adcdb68 100644 --- a/files/en-us/web/http/headers/accept-encoding/index.md +++ b/files/en-us/web/http/headers/accept-encoding/index.md @@ -9,7 +9,7 @@ browser-compat: http.headers.Accept-Encoding The HTTP **`Accept-Encoding`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates the content encoding (usually a compression algorithm) that the recipient can understand. In requests, the server uses [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) to select one of the encoding proposals from the client and informs the client of that choice with the {{HTTPHeader("Content-Encoding")}} response header. -In responses, it provides information about which encodings are preferred in the content of a subsequent request to the same resource. +In responses, it provides information about which content encodings the server can understand in messages to the requested resource, so that the encoding can be used in subsequent requests to the resource. For example, this might be sent in the response to a `PUT` request to a resource that used an unsupported encoding. Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the `identity` value is also acceptable. This happens in two common cases: