Skip to content

json-comp: serve brotli when the client offers it (Accept-Encoding: gzip, br) — currently always gzip #87

Description

@enghitalo

The json-comp profile request is GET /json/25?m=4 with Accept-Encoding: gzip, br (requests/json-gzip-25.raw). The entry's accepts_gzip only substring-matches gzip (frameworks/vanilla-epoll/main.v:1119, same in io_uring) and write_json_gzip hardcodes Content-Encoding: gzip — so vanilla always ships gzip even though the client also accepts br, which is ~15–20% smaller for this JSON. That's bandwidth/rps left on the table on a compressed profile.

The body is built dynamically (count, m) and compressed at runtime, so serving br needs a brotli encoder — vanilla has compress.gzip but no brotli. This is therefore a lib/feature prerequisite, not a pure entry change:

  • Add a brotli compressor (vlib or a C-shim libbrotlienc), then negotiate br ahead of gzip in accepts_gzip/write_json_* (honor the client's offer; the existing per-(count,m) compressed-response cache already amortizes the cost, so runtime brotli is hit only on cache miss).

Lower priority / future: vanilla is already top on json-comp today; this is upside, not a regression.

Fix location: vanilla lib (new brotli encoder) + the json-comp handler in both HttpArena entries.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions