Fix compress middleware Accept-Encoding parsing (substring + q=0)

[queelius]

Summary

• Fix matchAcceptEncoding to use exact encoding name comparison instead of strings.Contains substring matching
• Respect q=0 quality values per RFC 9110 Section 12.5.3, which means "encoding not acceptable"
• Previously, Accept-Encoding: gzip;q=0 would still compress with gzip, and Accept-Encoding: br could incorrectly match a hypothetical encoder named b

Fixes #1069

Test plan

• New TestMatchAcceptEncoding unit tests cover exact matching, whitespace handling, quality values, and substring rejection
• New TestCompressorRespectsQualityZero integration test confirms end-to-end fix
• All existing tests pass (go test ./...)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes middleware/compress’s Accept-Encoding handling to avoid substring-based false positives and to respect q=0 (encoding explicitly not acceptable), addressing #1069.

Changes:

• Update matchAcceptEncoding to compare encoding tokens exactly (not via substring matching).
• Add q=0 handling so explicitly rejected encodings are not selected.
• Add unit/integration tests for exact matching, whitespace, and q=0 behavior.

Reviewed changes

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

File	Description
middleware/compress.go	Updates Accept-Encoding matching logic to use exact token matching and skip encodings with q=0.
middleware/compress_test.go	Adds new unit and integration tests covering exact matching and q=0 rejection behavior.

---

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

[Copilot]

matchAcceptEncoding only checks q=... if the params string starts with q=. If the header includes additional params after q (e.g. gzip;q=0;ext=1) or an invalid qvalue that still parses (NaN/Inf) / is out of [0,1], this function will treat the encoding as acceptable and return true. Consider splitting params on ; and scanning for a q= parameter, and treating parse errors / NaN / out-of-range values as q=0 (i.e., not acceptable) to stay RFC-compliant and avoid accidental gzip selection.

[Copilot]

TestCompressorRespectsQualityZero currently only asserts that the response is not gzipped. This will still pass if compression is disabled entirely, which would miss regressions. Since the request header includes deflate and the compressor supports it, assert that Content-Encoding is deflate (or at least non-empty) to verify the intended fallback behavior end-to-end.

Suggested change

	// gzip;q=0 means "I do NOT accept gzip"
	resp, _ := testRequestWithAcceptedEncodings(t, ts, "GET", "/", "gzip;q=0, deflate")
	if got := resp.Header.Get("Content-Encoding"); got == "gzip" {
	t.Errorf("server used gzip despite q=0; Content-Encoding = %q", got)
	}
	// gzip;q=0 means "I do NOT accept gzip", but deflate is acceptable.
	resp, _ := testRequestWithAcceptedEncodings(t, ts, "GET", "/", "gzip;q=0, deflate")
	got := resp.Header.Get("Content-Encoding")
	if got == "" {
	t.Fatalf("expected a compressed response using a fallback encoding, got no Content-Encoding header")
	}
	if got == "gzip" {
	t.Errorf("server used gzip despite q=0; Content-Encoding = %q", got)
	}
	if got != "deflate" {
	t.Errorf("expected deflate fallback when gzip is disallowed; got Content-Encoding = %q", got)
	}