The current implementation of HttpClientStreamableHttpTransport / HttpClientSseClientTransport do not handle 401 errors

[rcosnita-flowx]

Bug description
The MCP protocol describes the discovery of supported security mechanism by returning to the caller a 401 error and indicating through WWW-Authenticate header the location of a protected resource.

The current version of the sdk does not treat this explicitly and suppresses the headers received from the MCP.

Environment
Java: 21
Sprint AI MCP version: 1.1.0

Steps to reproduce

1. Try to connect to an MCP server that requires authorization (see https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#protected-resource-metadata-discovery-requirements)
2. There is no way to understand where the authorization should be fetched from.

Expected behavior

1. Ideally, the MCP client in the SDK should return the WWW-Authenticate header value so that consumers can do the security discovery on their own. Ideally, the complete discovery should be done by the sdk and the client simply receives the details.

Minimal Patched Version of a potential solution

transport.zip

I patched the transport implementation classes in a minimal way so that 401 -> checked exception.