Correct Accept-Encoding parsing for tokens and q-values

[metsw24-max]

What do these changes do?

Fix Accept-Encoding parsing to use exact token matching, properly handle comma-separated values, and respect q values. Adds a regression test.

Are there changes in behavior for the user?

Yes:

Invalid tokens (e.g., xgzip) no longer match valid encodings
Encodings with q=0 are ignored
Valid encodings work as expected

Is it a substantial burden for the maintainers to support this?

No. The logic is clearer and covered by tests, improving maintainability.

[Dreamsorcerer]

So, this is a developer sending a response. I'm not sure the additional complexity and overhead here is worth the validation. It seems unlikely that a developer is going to make such a mistake (and not notice it when testing).

[metsw24-max]

I simplified this.

I removed the extra validation in the no-text constructor path and updated tests accordingly, so we no longer raise for header plus content_type or charset in that developer-facing case. The stricter conflict check when text is provided remains unchanged.

[codecov]

Codecov Report

❌ Patch coverage is 87.27273% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 98.90%. Comparing base (24ed3b3) to head (d79b531).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
aiohttp/web_response.py	66.66%	4 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12390      +/-   ##
==========================================
- Coverage   98.92%   98.90%   -0.02%     
==========================================
  Files         134      134              
  Lines       46616    46660      +44     
  Branches     2429     2434       +5     
==========================================
+ Hits        46114    46151      +37     
- Misses        373      377       +4     
- Partials      129      132       +3     

Flag	Coverage Δ
CI-GHA	98.97% <87.27%> (-0.02%)	⬇️
OS-Linux	98.70% <87.27%> (-0.02%)	⬇️
OS-Windows	96.97% <87.27%> (-0.02%)	⬇️
OS-macOS	97.86% <87.27%> (-0.02%)	⬇️
Py-3.10.11	97.38% <87.27%> (-0.02%)	⬇️
Py-3.10.20	97.85% <87.27%> (-0.01%)	⬇️
Py-3.11.15	98.10% <87.27%> (-0.02%)	⬇️
Py-3.11.9	97.63% <87.27%> (-0.02%)	⬇️
Py-3.12.10	97.72% <87.27%> (-0.02%)	⬇️
Py-3.12.13	98.19% <87.27%> (-0.01%)	⬇️
Py-3.13.13	98.43% <87.27%> (-0.02%)	⬇️
Py-3.14.4	98.49% <87.27%> (-0.01%)	⬇️
Py-3.14.4t	97.50% <87.27%> (-0.02%)	⬇️
Py-pypy3.11.15-7.3.21	97.33% <87.27%> (-0.02%)	⬇️
VM-macos	97.86% <87.27%> (-0.02%)	⬇️
VM-ubuntu	98.70% <87.27%> (-0.02%)	⬇️
VM-windows	96.97% <87.27%> (-0.02%)	⬇️
cython-coverage	38.23% <87.27%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 67 untouched benchmarks
⏩ 4 skipped benchmarks¹

---

_{Comparing metsw24-max:accept-encoding-parsing (d79b531) with master (24ed3b3)}

Footnotes

1. 4 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Dreamsorcerer]

I simplified this.

I removed the extra validation in the no-text constructor path and updated tests accordingly, so we no longer raise for header plus content_type or charset in that developer-facing case. The stricter conflict check when text is provided remains unchanged.

You appear to have removed an existing, cheap check, while leaving all your complex validation in. My comment still stands and I think there needs to be a strong argument for the inclusion of this code.