Solon v3.5.0

Context-Path 的两种配置(很重要)

</> markdown

context-path 概念早期可能是出现在 servelt 容器。比如 tomcat 在部署应用(或模块)时,每个应用(或模块)会配置一个 context-path,起到隔离和避免路径冲突的效果。

对 solon 而言,相当于一个 webapp 的“路径前缀”(且与友商的配置略有不同)。

1、所谓路径前缀

比如果有应用地址(未配置 context-path 时):http://xxx/test/get

当配置了context-path /demo/ 后就需要用 http://xxx/demo/test/get 发起请求(在域名之后,多了段前缀)。

2、关于 context-path 的两种配置(基于 pathNew 的变化实现)

配置差别差别说明
server.contextPath: "/test-service/" 原路径仍能访问(v1.11.2 后支持)
server.contextPath: "!/test-service/"! 开头强制,原路径不可访问(v2.6.3 后支持)

当有 context-path 配置时

接口说明
ctx.path()是原始请求路径
ctx.pathNew()是去掉 context-path 后的请求路径

3、两种配置效果示例说明

比如有原始地址:http://xxx/test,使用不同配置的效果:

请求地址无配置"/test-service/""!/test-service/"
http://xxx/test (原路径)可访问可访问404 错误
http://xxx/test-service/test404 错误可访问可访问

提醒:一般情况使用,添加 ! (表示强制)才是大多数人的预期效果。

4、为什么要有两种配置?

在集群环境(比如微服务)做内部的 http rpc (或者 http call)请求时。如果 server 加了 context-path(或者变更),client 就必须要修改请求路径。没办法作到一套代码到处可用。

所以有了 “原路径仍能访问” 的配置策略。可以实现外部如何变化,内部请求都可不变!

5、为什么默认不是“强制”的策略?

在生产部署时,当遇见有 context-path 需求的场景。一般会有 nginx 或 tomcat 等,本身就有 path 前缀配置,相当于已经起到了过滤的效果,应用只需要支持有前缀的需求。

所以默认不采用“强制”方式,可以同时兼容两种应用需求。(但有些场景下,确实需要强制)