ModelContextProtocol C SDK中SSE客户端传输头信息失效问题解析

问题背景

在使用ModelContextProtocol的C# SDK进行服务器发送事件(SSE)通信时，开发者发现通过TransportOptions字典设置的附加头信息(AdditionalHeaders)未能正确传递到服务端。这是一个影响认证和自定义通信的关键功能缺陷。

技术分析

SSE客户端传输实现中存在一个明显的设计疏漏：虽然SseClientTransportOptions类提供了AdditionalHeaders属性用于接收开发者配置的头信息，但在实际创建HttpRequestMessage时，这些头信息并未被正确应用到请求中。

核心问题位于SseClientSessionTransport类的实现中，当建立SSE连接时，仅设置了"text/event-stream"的媒体类型头，而忽略了开发者通过TransportOptions配置的其他头信息。

临时解决方案

在官方修复发布前，开发者可以采用以下两种临时解决方案：

1. 自定义HttpClient方案：

var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Add("ACCESS_TOKEN", "your_token_value");

var transport = new SseClientTransport(
    new SseClientTransportOptions(),
    serverConfig,
    httpClient,
    loggerFactory);

2. 服务端认证方案： 对于服务端开发者，可以利用IHttpContextAccessor获取请求头信息进行认证：

[McpServerToolType]
public class SecureTool(IHttpContextAccessor contextAccessor)
{
    [McpServerTool]
    public string SecureOperation()
    {
        var token = contextAccessor.HttpContext?.Request.Headers["ACCESS_TOKEN"];
        // 执行认证逻辑
        return "操作成功";
    }
}

安全注意事项

开发者需要注意当前版本(MapMcp)的安全限制：

1. 不会自动验证/message端点请求是否来自同一用户
2. SSE连接初始认证后，后续消息需要自行实现验证逻辑
3. 建议在生产环境中实现完整的请求验证机制

技术展望

根据项目维护者的反馈，未来版本可能会：

1. 完善头信息的自动传递机制
2. 提供更优雅的认证集成方案
3. 增强SSE连接的安全性设计
4. 优化HttpContext在工具类中的访问体验

最佳实践建议

1. 对于客户端开发：

• 优先使用自定义HttpClient方案传递关键头信息
• 考虑实现请求重试机制处理认证失败情况

2. 对于服务端开发：

• 实现双重认证（SSE连接认证和消息处理认证）
• 考虑使用中间件统一处理认证逻辑
• 记录详细的访问日志用于安全审计

这个问题展示了在实现实时通信协议时常见的认证挑战，开发者需要理解底层通信机制才能设计出安全可靠的解决方案。随着项目的迭代更新，预期这些痛点将得到系统性的解决。