[Rust] Configurable default features from reqwest dependency

[JMLX42]

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work and description provides validation details.
• Run build and sample generation scripts:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

• File PR against the correct branch: master
• If solving a reported issue, reference it using GitHub's linking syntax (fixes [Rust] The reqwest(-trait) library must not enable any default feature #21933)
• For language-specific PRs, @mention relevant technical committee members: @frol @farcaller @richardwhiuk @paladinzh @jacob-pro

Description

This PR removes the default features (specifically native-tls) from the reqwest dependency in the Rust client generator. This allows users to explicitly choose their TLS backend without automatically including openssl-sys as a transitive dependency.

Problem

As described in #21933, the current implementation sets default = ["native-tls"], which:

• Always pulls in openssl-sys as a transitive dependency
• Can cause build issues for certain targets like Android
• May include an "unsafe SSL implementation" that users don't need

Solution

• Modified Cargo.mustache template to set default = [] instead of default = ["native-tls"]
• Users can now explicitly enable their preferred TLS backend using feature flags

Available TLS Backends

After this change, users can explicitly select:

• native-tls: Uses platform-native TLS (OpenSSL on Linux, SChannel on Windows, Security Framework on macOS)
• rustls-tls: Uses rustls, a pure Rust TLS implementation
• default-tls: Uses reqwest's default choice

Breaking Change Notice

⚠️ This is a breaking change. Users will need to explicitly enable a TLS backend feature in their Cargo.toml:

This is not a breaking change (cf #22041 (comment))

Testing

• Built the project successfully with Maven
• Regenerated all Rust samples
• Verified that generated Cargo.toml files have empty default features list
• Exported documentation

Fixes #21933

[JMLX42]

@frol @farcaller @richardwhiuk @paladinzh @jacob-pro @dsteeley for review

[dsteeley]

LGTM, thanks for raising as a follow-up to the previous PR.

[wing328]

⚠️ This is a breaking change. Users will need to explicitly enable a TLS backend feature in their Cargo.toml:

what about adding an option to let users choose?

[JMLX42]

what about adding an option to let users choose?

An option to set a Cargo feature? Sounds a bit complicated to me.

But if that's a show stopper for 7.16 then yes, I'll do it.

[wing328]

the next release v7.17.0 allows breaking changes with fallback so if you can add an option with native-tls (or empty) as the default, then we can include this enhancement in the upcoming release

[wing328]

thanks again for putting together the following to highlight it's a breaking change:

Breaking Change Notice

⚠️ This is a breaking change. Users will need to explicitly enable a TLS backend feature in their Cargo.toml:

[dependencies]
my_api_client = { version = "1.0", features = ["native-tls"] }
# or
my_api_client = { version = "1.0", features = ["rustls-tls"] }

is it correct to say that users need to manually update the auto-generated Cargo.toml in order to consume the API client?

[JMLX42]

This is a breaking change. Users will need to explicitly enable a TLS backend feature in their Cargo.toml:

There was a typo in the codeblock so I fixed it.

is it correct to say that users need to manually update the auto-generated Cargo.toml in order to consume the API client?

No. There will be 0 required modification of the generated Cargo.toml.

What the codeblock shows is that the feature is enabled by the user's crate that will use the generated SDK.

the next release v7.17.0 allows breaking changes with fallback so if you can add an option with native-tls (or empty) as the default, then we can include this enhancement in the upcoming release

OK so IMHO to be backward compatible the default value for this option will have to be the current default feature, so "native-tls".

[JMLX42]

I've updated the PR to address the feedback. Here's what changed:

Changes Made

Added a new generator option reqwestDefaultFeatures that allows users to configure the default Cargo features for the reqwest dependency.

Key Points

✅ Backward Compatible: Default value is ["native-tls"] - maintains existing behavior
✅ Flexible: Supports array of strings for forward compatibility
✅ Meets v7.17.0 criteria: Breaking change with fallback

Usage

YAML configuration:

additionalProperties:
  reqwestDefaultFeatures: []  # No default features
  # or
  reqwestDefaultFeatures: ["rustls-tls"]  # Use rustls
  # or  
  reqwestDefaultFeatures: ["native-tls", "cookies"]  # Multiple features

CLI:

--additional-properties=reqwestDefaultFeatures=  # Empty for no defaults
--additional-properties=reqwestDefaultFeatures=rustls-tls  # Single feature
--additional-properties=reqwestDefaultFeatures=rustls-tls,cookies  # Multiple (comma-separated)

Implementation Details

• Added REQWEST_DEFAULT_FEATURES constant and field to RustClientCodegen
• Default value: Arrays.asList("native-tls")
• Processes both List<String> (from YAML) and comma-separated strings (from CLI)
• Updated Cargo.mustache template to use array iteration with proper comma handling
• Applied to both reqwest and reqwest-trait library sections

All builds, samples, and documentation have been regenerated successfully.

[wing328]

nice 👍

thanks for the contribution