fix(middleware): respect Accept-Encoding q-values in Gzip

[DucMinhNe]

The Gzip middleware decides whether to compress a response with a naive substring check:

if strings.Contains(c.Request().Header.Get(echo.HeaderAcceptEncoding), gzipScheme) {

Per RFC 9110 §12.5.3 this is incorrect in two ways:

• Accept-Encoding: gzip;q=0 explicitly means the client does not accept gzip ("A qvalue of 0 means not acceptable"), yet strings.Contains still enables compression.
• A distinct coding token such as x-gzip or supergzip substring-matches "gzip" and wrongly triggers compression.

Repro (before the fix)

A request with Accept-Encoding: gzip;q=0 returns a gzip-encoded body (Content-Encoding: gzip), even though the client asked not to be gzipped.

Fix

Replace the substring check with a small acceptsGzip parser that:

• splits the header into codings,
• matches the gzip token (or *) exactly, and
• honours the q-value, skipping compression on an explicit q=0 rejection.

Tests

Added TestGzip_AcceptEncodingQValue and TestAcceptsGzip covering gzip;q=0, q>0, multi-coding headers, identity, the * wildcard, and the supergzip/x-gzip substring false-positives.

go test ./middleware/..., gofmt -l and go vet ./middleware/ are all clean. No public API change; behaviour only changes for headers that were previously handled incorrectly.

[Copilot]

Pull request overview

This PR fixes Echo’s Gzip middleware decision logic by replacing a naive strings.Contains check on Accept-Encoding with token-based parsing that aims to follow RFC 9110 §12.5.3 (exact token matching and honoring q values).

Changes:

• Introduces an acceptsGzip helper to parse Accept-Encoding codings and q parameters instead of substring matching.
• Updates the Gzip middleware to use acceptsGzip when deciding whether to enable gzip compression.
• Adds tests covering q=0, wildcard *, multiple codings, and substring false-positives like supergzip/x-gzip.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
middleware/compress.go	Adds acceptsGzip/parseCoding and switches middleware gating from substring match to parsed logic.
middleware/compress_test.go	Adds regression tests for Accept-Encoding parsing and gzip enablement behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aldas]

Are there examples how other frameworks, maybe in other programming languages are dealing with this?

[DucMinhNe]

Hey @aldas, sorry for the delayed reply!

Here is a quick look at how other frameworks and standard libraries handle this:

1. Go ecosystem:

   • klauspost/compress/gzhttp (widely used in Go for gzip handling): parses Accept-Encoding by splitting on commas, extracts parameters like ;q=, and specifically discards any encoding if q == 0 (or q <= 0). It also matches full coding tokens rather than substrings so x-gzip isn't mistaken for gzip.
   • Caddy (modules/caddyhttp/encode/encode.go): parses the header into tokens with their associated quality weights, sorting accepted encodings and ignoring anything with q == 0.
   • Go stdlib (golang.org/x/net/http/httpguts / net/http): uses HeaderValuesContainsToken for token boundary checks rather than naive substring matching to avoid false positives.

2. Node.js (expressjs/compression / jshttp/negotiator):

   • Express's compression middleware delegates encoding resolution to negotiator (negotiator/lib/encoding.js). It parses comma-delimited tokens, extracts ;q=, and filters out any item with q === 0 per RFC 9110 §12.5.3.

3. Python (Werkzeug / Flask):

   • Werkzeug's Accept data structure (werkzeug.datastructures.accept.Accept) parses Accept-Encoding into (value, quality) pairs, sorting by quality and treating quality == 0 as explicitly refused.

4. Rust (tower-http):

   • In tower-http's compression layer, Accept-Encoding values are parsed token-by-token while honoring quality weights to select the negotiated encoding, rejecting zero weights.

Most frameworks do lightweight token parsing + q=0 filtering here because full content-negotiation isn't strictly necessary for a dedicated gzip middleware, but simple substring matching (strings.Contains) causes issues whenever clients send gzip;q=0 or alternative tokens like x-gzip. The acceptsGzip helper in this PR was kept intentionally small and dependency-free to follow that same pattern.