I can build the feature if maintainers have no objections to the proposed implementation.
Motivation
As developers migrate existing applications to Rust, ensuring seamless backward compatibility is crucial. Many of these applications already recognize "x-gzip" as a valid encoding for gzip. Adhering to RFC9110, which advises treating "x-gzip" as synonymous with "gzip", we can facilitate a smoother transition for these applications. This change streamlines the migration process and ensures that our Rust-based solutions remain backward compatible, fostering wider adoption and minimizing potential integration issues.
Proposal
The easiest implementation I see is to add || s.eq_ignore_ascii_case("x-gzip") to content_encoding.rs:64 with additional tests:
Should compress response with gzip
And return content-type: gzip
When accept-encoding is x-gzip
Should compress response with gzip
When accept-encoding has both x-gzip and deflate
(to test that it's treated the same as gzip for ordering)
For situations when both gzip and x-gzip are provided, the behavior would be as if gzip was specified twice.
Alternatives
I considered building an outer layer that changes x-gzip to gzip in the request before it's passed to the Compression service, however, proper implementation would require parsing of the headers which would duplicate code of this crate.
As for alternatives to the suggested proposal, we could add this capability behind a new feature "compression-x-gzip" but I think it might be overkill. Open to other opinions though.
Out of scope
Since tower-http doesn't support compress, we will not add support for x-compress.
jplatte
commented
6 months ago
Feature Request
Add support for deprecated coding in Accept-Encoding "x-gzip".
According to RFC9110:
https://www.rfc-editor.org/rfc/rfc9110.html#section-18.6 https://www.rfc-editor.org/rfc/rfc9110.html#section-8.4.1.3
I can build the feature if maintainers have no objections to the proposed implementation.
Motivation
As developers migrate existing applications to Rust, ensuring seamless backward compatibility is crucial. Many of these applications already recognize "x-gzip" as a valid encoding for gzip. Adhering to RFC9110, which advises treating "x-gzip" as synonymous with "gzip", we can facilitate a smoother transition for these applications. This change streamlines the migration process and ensures that our Rust-based solutions remain backward compatible, fostering wider adoption and minimizing potential integration issues.
Proposal
The easiest implementation I see is to add
|| s.eq_ignore_ascii_case("x-gzip")to content_encoding.rs:64 with additional tests:Should compress response with gzip And return content-type: gzip When accept-encoding is x-gzip
Should compress response with gzip When accept-encoding has both x-gzip and deflate (to test that it's treated the same as gzip for ordering)
For situations when both gzip and x-gzip are provided, the behavior would be as if gzip was specified twice.
Alternatives
I considered building an outer layer that changes x-gzip to gzip in the request before it's passed to the Compression service, however, proper implementation would require parsing of the headers which would duplicate code of this crate.
As for alternatives to the suggested proposal, we could add this capability behind a new feature "compression-x-gzip" but I think it might be overkill. Open to other opinions though.
Out of scope
Since tower-http doesn't support
compress, we will not add support forx-compress.