ServiceComb Java Chassis 3.0.2 版本中Authorization请求头传递问题解析

问题背景

在ServiceComb Java Chassis 3.0.2版本中，开发者在使用RPC方式进行远程服务调用时，发现一个特殊现象：当接口方法参数中包含名为"Authorization"的请求头时，该参数值无法正确传递到服务端。这是一个值得关注的问题，因为Authorization请求头在认证授权场景中非常关键。

问题现象

开发者在使用ServiceComb的RPC调用方式时，定义了一个包含Authorization请求头的接口方法：

@RequestMapping(path = "/")
public interface TestServiceApi {
    @GetMapping(value = "/health/check2", produces = {"application/json"})
    TenantDetailInfo getTenantDetailInfo(
        @RequestHeader(value = "test") String test,
        @RequestParam(value = "param") String param,
        @RequestHeader("Authorization") String authorization);
}

当通过RPC代理调用此方法时，服务端接收到的Authorization请求头始终为null，而其他请求头如"test"则可以正常传递。

问题根源分析

经过深入分析，这个问题与Swagger 3.0规范的变化有关。在Swagger/OpenAPI 3.0及更高版本中，出于安全考虑，规范对Authorization这类特殊请求头做了特殊处理。根据OpenAPI 3.1.0规范，Authorization这类安全相关的请求头需要特殊的配置方式，而默认情况下可能会被过滤或忽略。

解决方案

目前发现有两种可行的解决方案：

1. 参数名首字母大写方案： 将方法参数名改为首字母大写的"Authorization"，可以解决传递问题：

@RequestHeader("Authorization") String Authorization

这种方案虽然有效，但从代码规范角度看可能不够优雅，因为Java方法参数通常采用小驼峰命名法。

2. 改用REST调用方式： 如果业务场景允许，可以考虑不使用RPC方式，而是采用纯REST风格的调用。这种方式下，请求头的传递通常不会受到限制。

技术建议

对于需要在ServiceComb中使用Authorization请求头的开发者，建议：

1. 如果必须使用RPC方式，可以采用参数名首字母大写的临时解决方案
2. 评估是否可以将相关接口改为REST风格调用
3. 关注ServiceComb后续版本更新，看是否有更优雅的解决方案
4. 对于关键的安全相关请求头，建议在代码中添加额外的日志和校验，确保参数传递的正确性

总结

ServiceComb Java Chassis 3.0.2版本中出现的Authorization请求头传递问题，本质上是由于Swagger/OpenAPI规范升级带来的兼容性问题。开发者在处理安全相关的请求头时需要特别注意这类特殊情况。通过合理的参数命名或调用方式调整，可以有效地解决这一问题。