fix(middleware): match gzip Content-Encoding case-insensitively#3056
Conversation
Proxies and clients may send Content-Encoding: Gzip or GZIP. Exact string compare skipped decompression. Trim and EqualFold against "gzip".
|
I am not agains this change but please give us real world example then |
|
This is primarily RFC compliance, not a custom client quirk. RFC 9110 §8.4.1 (and earlier HTTP RFCs) define content codings as case-insensitive. So Real-world sources of non-lowercase values:
The |
Drop TrimSpace so the change is strictly RFC 9110 case-insensitivity for content codings, per review discussion.
|
Follow-up: I dropped the Concrete cases this fixes:
Happy to adjust further if you want a different approach. |
c4b0fdd to
c7d2c83
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3056 +/- ##
=======================================
Coverage 93.34% 93.35%
=======================================
Files 43 43
Lines 4735 4737 +2
=======================================
+ Hits 4420 4422 +2
Misses 192 192
Partials 123 123 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
Decompress middleware only accepted exact
Content-Encoding: gzip. Values likeGziporGZIPwere skipped.Change
strings.EqualFoldafter trim.Test plan
go test ./middleware -run TestDecompress