Skip to content

Switch encoding preference from client controlled to server #322

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
anuraaga wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Switch encoding preference from client controlled to server #322

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2678928
Switch encoding preference from client controlled to server
anuraaga Feb 4, 2026
c642b97
Examples
anuraaga Feb 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 13 additions & 5 deletions docs/protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -181,11 +181,19 @@ If the client omits **Accept-Encoding**, servers must assume that the client
accepts the **Content-Encoding** used for the request if present. Servers must
assume that all clients accept "identity" as their least preferred encoding,
even when **Accept-Encoding** is omitted. Servers should treat **Accept-Encoding**
as an ordered list, with the client's most preferred encoding first and least
preferred encoding last. This is a simplification fo standard HTTP semantics
that excludes quality values. If the client uses an unsupported **Content-Encoding**,
servers should return an error with code "unimplemented" and a message listing the
supported encodings.
as a list of equal preference and decide an appropriate encoding based on it.
This is a simplification fo standard HTTP semantics that excludes quality values.
If a user configures a server with an ordered list of encodings, it should be compared
in order to client's **Accept-Encoding** to determine the encoding for a response.

For example, if the client's **Accept-Encoding** is **gzip,br,zstd**,

- If the server is configured with **gzip**, the selected encoding is **gzip**
- If the server is configured **gzip,zstd,br**, the selected encoding is **gzip**
- If the server is configured **br,zstd,gzip**, the selected encoding is **br**

If the client uses an unsupported **Content-Encoding**, servers should return an
error with code "unimplemented" and a message listing the supported encodings.
Copy link
Copy Markdown

@codefromthecrypt codefromthecrypt Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could it be helpful or appropriate to add an example of both sides configuration and which wins? This might underscore the conflict that led to this PR

Copy link
Copy Markdown
Contributor Author

@anuraaga anuraaga Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, added some. If they seem too noisy, can cut down or remove them anyways, works either way for me

Copy link
Copy Markdown

@codefromthecrypt codefromthecrypt Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!


If **Timeout** is omitted, the server should assume an infinite timeout. The
protocol accommodates timeouts of more than 100 days. Client implementations
Expand Down