官网:https://smartboot.tech/smart-servlet/
国产中间件的"兼容性",到底有没有水分?
这次 smart-servlet 没有选择回答,而是直接把官方报告摆上了台面。
信创合规、全面兼容 Servlet 规范——这类话,几乎每个国产中间件项目都会在 README 里写一遍。但你有没有想过:这句话背后,到底有没有人真的拿官方标准跑过一遍?
大部分项目的"兼容",停留在 README 里的一句话。
smart-servlet 选择了一种更麻烦、但更实在的方式:把 Jakarta Servlet 官方 TCK(Technology Compatibility Kit,判定一个 Servlet 容器是否真正符合规范的官方标准)完整跑一遍,报告原样公开,谁都能验证。
这是今天刚跑出来的成绩单
| 指标 |
结果 |
| TCK 版本 |
tck-build 3.2 |
| 测试用例总数 |
1724 |
| Errors |
4 |
| Failures |
0 |
| Skipped |
0 |
| 通过率 |
99.8% |
| 总耗时 |
414.9 秒(约 7 分钟) |
通过率可以被验证,宣传文案不能。
这 1724 条用例里,没有一条是"差不多就行"——Failure 是 0,意味着在官方明确定义的每一条行为断言上,smart-servlet 没有一处不达标。报告里仅存的 4 个 Error,我们也没有藏起来:逐个排查后确认,对应的都是规范里极为冷门、如今几乎不会被实际业务用到的边缘场景。距离 100% 还有这最后一点距离,会持续推进——但我们不打算等到凑出一个好看的"100%"才公开报告。
这份报告比上一版又往前走了一步:测试用例从 1717 条增加到 1724 条,是跟着官方规范同步升级的结果——规范每更新一次 TCK,相关模块就要重新核对一遍细节,确认是不是真的字字对应规范,而不是看起来差不多。
为什么这件事,企业用户应该在意
如果你是技术负责人,要做中间件选型或者过信创合规审查,TCK 通过率其实比任何宣传话术都值钱:
- 它是可验证的事实,不是营销话术。 报告里的每一条用例都能复现,不需要"相信",只需要"跑一遍"。
- 它直接决定了迁移成本。 通过率越高,意味着把现有 Tomcat / Undertow 上跑的应用换到 smart-servlet,行为差异越小、踩坑概率越低。
- 它是长期投入的信号。 规范每次升级 TCK,团队都愿意跟进、愿意公开结果,这比"一次性兼容"更能说明一个项目是不是真打算长期维护。
细节控才会留意到的两处优化
成绩单之外,这次还顺手改了两处容易被忽略、但按规范来说"必须改对"的细节。
HTTP/2 Server Push 的 Cookie 处理。 以前是把每个 Cookie 单独塞进一个 Header 推给客户端,这既不符合 RFC 6265 里"一个请求只能有一个 Cookie 头"的规定,也会把已经标记失效(maxAge == 0)的 Cookie 顺手推送出去。现在改成统一拼接成一个 Cookie 头,并提前过滤掉失效的 Cookie:
if (!response.getCookies().isEmpty()) {
StringBuilder sb = new StringBuilder();
response.getCookies().stream()
.filter(cookie -> cookie.getMaxAge() != 0)
.forEach(cookie -> {
sb.append(cookie.getName()).append('=').append(cookie.getValue()).append(';');
});
if (sb.length() > 0) {
pushRequest.setHeader(HeaderName.COOKIE.getLowCaseName(), sb.substring(0, sb.length() - 1));
}
}
web.xml 的 cookie-config 配置。 规范允许在部署描述符里直接声明 Session Cookie 的名称、作用域、HttpOnly、Secure、最大有效期等属性,不用写进代码里。这次补齐了之前解析不完整的问题,web.xml 里声明的配置现在能完整生效,迁移过来的项目不需要再额外做兼容处理。
写在最后
1724 项用例、99.8% 通过率、0 Failure——这张成绩单,smart-servlet 选择直接公开,而不是包装成一句"全面兼容"。剩下的 0.2%,会持续推进,目标是 100%。
如果你的团队正在做信创 / 国产化中间件选型,把这篇转给做技术决策的同事——这可能是你能找到的、最不"营销"的一份兼容性证明。
欢迎拉到自己的环境里跑一遍,也欢迎在 GitHub 上提 Issue——挑刺,正是这个项目最欢迎的反馈方式。