Skip to content

feat: support zstd response encoding based on Accept-Encoding#62

Open
mo4islona wants to merge 1 commit into
masterfrom
fix/zstd-response-encoding
Open

feat: support zstd response encoding based on Accept-Encoding#62
mo4islona wants to merge 1 commit into
masterfrom
fix/zstd-response-encoding

Conversation

@mo4islona

@mo4islona mo4islona commented Mar 25, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Respond with zstd compression when the client mentions zstd in Accept-Encoding, otherwise fall back to gzip (backward compatible default)
  • No q-value / RFC parsing — this is an internal API between the SDK and hotblocks, so a simple "client supports zstd → use zstd" check is enough (per review feedback)
  • Responses include Vary: Accept-Encoding

Changes

  • New crates/hotblocks/src/encoding.rs: ContentEncoding enum (Gzip/Zstd) with a trivial from_headers check
  • api.rs: detect encoding from request headers, set content-encoding/vary response headers
  • running.rs: Compressor enum wrapping GzEncoder/ZstdEncoder (level 1), selected per request
  • response.rs, service.rs: pass the encoding through the query pipeline

Copilot AI review requested due to automatic review settings March 25, 2026 08:12
@mo4islona mo4islona requested a review from kalabukdima March 25, 2026 08:14

This comment was marked as outdated.

@mo4islona mo4islona force-pushed the fix/zstd-response-encoding branch 2 times, most recently from 84fa936 to cfbd04c Compare March 25, 2026 11:42
Comment thread crates/hotblocks/src/encoding.rs Outdated
/// See <https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.4>
/// At equal q, prefers zstd over gzip.
/// Returns None if neither gzip nor zstd is accepted.
pub fn from_accept_encoding(header: Option<&str>) -> Option<Self> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

How is it related to the hotblocks? If axum doesn't support parsing these values, let's not overengineer and just prefer zstd. If it's actually needed, it should be a separate crate outside of this repo

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Do you mean we should ignore the q-numbers and check the first header and the first exact match for "zstd"?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yes, if the client supports zstd, just respond with zstd, otherwise — with gzip

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Done

Respect client Accept-Encoding header per RFC 7231:
- If client sends Accept-Encoding: zstd → respond with zstd compression
- If client sends Accept-Encoding: gzip → respond with gzip (backward compat)
- Quality values respected (e.g. "zstd;q=1.0, gzip;q=0.5" → zstd)
- At equal q, prefer zstd over gzip
- Default to gzip when no Accept-Encoding header present

Related: subsquid/squid-sdk#456
@mo4islona mo4islona force-pushed the fix/zstd-response-encoding branch from cfbd04c to c27964e Compare June 10, 2026 13:33
@mo4islona mo4islona requested a review from kalabukdima June 10, 2026 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants