Remove parity features

[heaths]

Resolves #2750 and replaces #2811 by removing the reqwest_rustls feature which was there only to enable reqwest/rustls-tls-native-roots-no-provider. But using resolver v2 and newer, dependents can already do that by just taking a dependency on reqwest themselves to add that feature. In some cases, they may need to import azure_core with default-features=false, but passing a different reqwest::Client via our TransportOptions is easy.

Not only will this scale better, but should help avoid opinionated feature selection that adversely impacts customers as with #2750.

[heaths]

Marking this as a draft since I want to add documentation to our README and/or TSG; however, first I want to create a couple crates external to the workspace to try scenarios such as enabling reqwest/rustls-tls and using rustls-symcrypt without pulling in openssl. Assuming all that works as hoped, I'll add/update documentation, examples, and whatever else and mark this ready.

[heaths]

I've created https://github.com/heaths/azsdk-rust-2750 to test out various scenarios. This is a work in progress.

[skeet70]

I can test this tomorrow in my internal PR to see if it prevents openssl from coming in as well.

[skeet70]

Locally with

azure_core = { path = "../../oss/azure-sdk-for-rust/sdk/core/azure_core", features = ["tokio"], default-features = false }
azure_identity = { path = "../../oss/azure-sdk-for-rust/sdk/identity/azure_identity", features = ["tokio"], default-features = false }
azure_security_keyvault_keys = { path = "../../oss/azure-sdk-for-rust/sdk/keyvault/azure_security_keyvault_keys" }
reqwest = { version = "0.12.23", default-features = false, features = [
    "json",
    "rustls-tls",
] }

and your branch checked out, I'm still seeing native-tls/openssl showing up (fresh vs not having the azure libs) in the Cargo.lock.

cargo tree -i native-tls
native-tls v0.2.14
├── hyper-tls v0.6.0
│   └── reqwest v0.12.23
│       ├── ironoxide v4.0.1
│       │   └── app v5.0.3-pre.12 (/Users/mumu/code/ironcore/app)
│       ├── app v5.0.3-pre.12 (/Users/mumu/code/ironcore/app)
│       └── typespec_client_core v0.7.0 (/Users/mumu/code/oss/azure-sdk-for-rust/sdk/typespec/typespec_client_core)
│           ├── azure_core v0.28.0 (/Users/mumu/code/oss/azure-sdk-for-rust/sdk/core/azure_core)
│           │   ├── azure_identity v0.28.0 (/Users/mumu/code/oss/azure-sdk-for-rust/sdk/identity/azure_identity)
│           │   │   └── app v5.0.3-pre.12 (/Users/mumu/code/ironcore/app)
│           │   ├── azure_security_keyvault_keys v0.7.0 (/Users/mumu/code/oss/azure-sdk-for-rust/sdk/keyvault/azure_security_keyvault_keys)
│           │   │   └──app v5.0.3-pre.12 (/Users/mumu/code/ironcore/app)
│           │   └── app v5.0.3-pre.12 (/Users/mumu/code/ironcore/app)
│           ├── azure_identity v0.28.0 (/Users/mumu/code/oss/azure-sdk-for-rust/sdk/identity/azure_identity) (*)
│           └── azure_security_keyvault_keys v0.7.0 (/Users/mumu/code/oss/azure-sdk-for-rust/sdk/keyvault/azure_security_keyvault_keys) (*)
├── reqwest v0.12.23 (*)
└── tokio-native-tls v0.3.1
    ├── hyper-tls v0.6.0 (*)
    └── reqwest v0.12.23 (*)

If I remove the azure libs it's not present, the only openssl-related things in my lockfile then are openssl-probe.

[heaths]

Thanks. After adding more use case examples, I can see where the problem is. Need to do a bit more feature refactoring, but does this seem like a reasonable path forward?

What I may need to do is have a reqwest feature that just enables support for reqwest, then separate features for its native-tls and rustls-tls features that are vastly different. Those would probably depend on reqwest just to make it obvious they depend on reqwest, and simplify our cfg(feature) checks (easier to maintain).

So if you wanted to pass your own reqwest::Client, you could still enable reqwest (default-features = false on the dependency, and probably gzip,deflate added for other reasons) but otherwise default-features = false, then add reqwest with whatever you wanted.

[heaths]

@skeet70 I made a few changes here and uploaded a few more scenarios in https://github.com/heaths/azsdk-rust-2750. In reqwest-rustls, for example, there's no "openssl": cargo tree -i openssl doesn't find any matching packages, nor is "openssl" found in Cargo.lock.

I'd love to hear what you think.

As for gzip (and deflate, though it appears none of our services support that while few support gzip), we're still debating whether to make that optional. It's easy enough to disable if you provide your own reqwest::Client, but you still pull in the dependencies, unfortunately.

[demoray]

Removing all of the reqwest pass-through features from the user-focused crates is a significantly positive step forward. It always felt clunky to me.

I appreciate the mechanism to provide alternate features into reqwest. This gives users a path forward to use rustls-symcrypt without requiring changes across all of the SDK. Specifying native-tls as a default paved-path, while enabling symcrypt, enables 1st party teams to that are working with the symcrypt team with minimal changes.

[heaths]

Removing all of the reqwest pass-through features

@demoray I'm still contemplating - and have a separate tracking issue open for a decision - keeping reqwest_deflate and reqwest_gzip if only to avoid flate2 and its dependencies being pulled in if you don't want compression. In fact, most Azure services don't support accept-encoding anyway so I might not even make those default but make them easy for service crates to enable if the services do support them without having to take an explicit dependency on reqwest, which then means they have to also deal with reqwest being optional but default, and redefine reqwest-native-tls as a passthrough.

[Copilot]

Pull Request Overview

This PR removes the reqwest_rustls feature that was originally added to enable reqwest/rustls-tls-native-roots-no-provider. The change leverages Cargo resolver v2 capabilities, allowing dependents to configure their own reqwest features directly rather than through Azure SDK feature flags. This reduces opinionated feature selection and allows for better scaling as customers can customize their TLS configuration independently.

Key Changes

• Removed reqwest_rustls feature from all crates
• Added reqwest_native_tls as a new default feature to maintain existing TLS behavior
• Updated feature dependencies to properly chain reqwest-related features

Reviewed Changes

Copilot reviewed 14 out of 16 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
sdk/typespec/typespec_client_core/src/http/clients/mod.rs	Simplified conditional compilation by removing reqwest_rustls feature checks
sdk/typespec/typespec_client_core/README.md	Updated feature documentation to remove reqwest_rustls and add reqwest_native-tls
sdk/typespec/typespec_client_core/Cargo.toml	Restructured features to remove reqwest_rustls and add proper feature chaining
sdk/core/azure_core/Cargo.toml	Updated feature definitions and dependencies to use reqwest_native_tls
Multiple SDK crates	Added explicit default features to inherit from azure_core/default
Cargo.toml	Set workspace azure_core dependency to default-features = false