Include reqwest in transport-streamble-http-client feature

[yulnr]

Closes #349

Motivation and Context

The transport-streamable-http-client feature makes use of the reqwest crate, but does not declare it as a component feature in the rmcp Cargo.toml. This prevents a project with rmcp from being compiled if they make use of the feature.

How Has This Been Tested?

I've managed to now compile my application using transport-streamable-http-client.

Breaking Changes

No

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[4t145]

How about moving this block to crates/rmcp/src/transport/common/reqwest/streamable_http_client.rs

The "this block" I say means the convertion from reqwest::Error to StreamableHttpError<reqwest::Error> in crates/rmcp/src/transport/streamable_http_client.rs

impl From<reqwest::Error> for StreamableHttpError<reqwest::Error> {
    fn from(e: reqwest::Error) -> Self {
        StreamableHttpError::Client(e)
    }
}

This will allow user to choose the client.

[yulnr]

How about moving this block to crates/rmcp/src/transport/common/reqwest/streamable_http_client.rs

The "this block" I say means the convertion from reqwest::Error to StreamableHttpError<reqwest::Error> in crates/rmcp/src/transport/streamable_http_client.rs

impl From<reqwest::Error> for StreamableHttpError<reqwest::Error> {
    fn from(e: reqwest::Error) -> Self {
        StreamableHttpError::Client(e)
    }
}

This will allow user to choose the client.

Good catch, updated.
Let me know if this is what you expected (I imagined you meant this as a incremental improvement) or if you you meant this as not hardcoding the reqwest dependency into the feature and already making this configurable from the outside.

[4t145]

I mean the latter. I have to admit that it could be confusing for user, so maybe we should add some guide, maybe in the document of StreamableHttpClientTransport

[yulnr]

@4t145 Ok, I've made the transports client-agnostic by:

• Moving reqwest-specific code to reqwest/ modules for both streamable HTTP and SSE clients
• Creating separate reqwest features (don't love the verbosity but I guess is very obvious):
  • transport-streamable-http-client-reqwest
  • transport-sse-client-reqwest
• Making base features reqwest-independent so users can choose their HTTP client

As you'll see I had to fix the same issue for SSE client since it was also forcing reqwest dependencies.
Also I did have to update the HeaderValue type to use String in the base modules to avoid reqwest-specific types.

Let me know if this what you what you had in mind.

[4t145]

Looks good now, just fix the ci

[yulnr]

Oops sorry should pass now

[4t145]

format check CI failed, just use just fmt

[4t145]

Thanks!