fix(middleware): match gzip Content-Encoding case-insensitively

[sonnemusk]

Summary

Decompress middleware only accepted exact Content-Encoding: gzip. Values like Gzip or GZIP were skipped.

Change

• Compare with strings.EqualFold after trim.
• Add regression tests for common case variants.

Test plan

• go test ./middleware -run TestDecompress

[aldas]

I am not agains this change but please give us real world example then gzip has spaces or different case. are we dealing theoretical problem, fix for some custom client or some widespread problem

[sonnemusk]

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 Content-Encoding: Gzip / GZIP are valid and should decompress the same as gzip.

Real-world sources of non-lowercase values:

• Some language HTTP clients / libraries canonicalize header names but leave coding tokens as the caller typed them.
• Reverse proxies and gateways that rewrite or re-emit Content-Encoding without lowercasing.
• Integration tests and generated clients often send Gzip.

The TrimSpace part is minor (malformed-but-common whitespace); the important bit is EqualFold for case-insensitivity required by the HTTP semantics. Happy to drop the trim if you only want the case fix.

[sonnemusk]

Follow-up: I dropped the TrimSpace part so this PR is only case-insensitivity via strings.EqualFold, matching RFC 9110 content-coding rules.

Concrete cases this fixes:

• clients/libraries that send Content-Encoding: Gzip or GZIP (valid per HTTP; previously skipped decompression and left a gzip body for handlers to read as plain text)
• e.g. some Java/OkHttp and generated clients historically emit mixed-case coding tokens

Happy to adjust further if you want a different approach.