Webx RPC 内部重定向的bug

最新推荐文章于 2021-09-03 16:16:08 发布

wsrspirit

最新推荐文章于 2021-09-03 16:16:08 发布

阅读量1.3k

点赞数

CC 4.0 BY-SA版权

分类专栏： Java 源码阅读文章标签： Webx 内部重定向 bug tomcat classload

本文链接：https://blog.csdn.net/WSRspirit/article/details/52245063

Java 同时被 2 个专栏收录

13 篇文章

订阅专栏

源码阅读

9 篇文章

订阅专栏

本文探讨了Webx框架中RPC内部重定向存在的问题，详细解析了RequestContext的包装过程和Tomcat的ClassLoader工作原理。由于Webx不再维护RPC功能，建议开发者通过创建相同类并覆盖相应方法来解决该问题，确保Tomcat优先加载自定义类。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

重定向是由RequestContext提供的一项功能，需要在webx.xml中配置

<rule pattern="^/****/docs/(\w+)">
    <substitution uri="http://**** flags="L,R">
    </substitution>
</rule>

其中去过去掉flags中的R将会是内部重定向，而不是302外部重定向。

但是我们在实际的使用过程中发现针对RPC的内部重定向会有bug，并没有重定向到目标的地址。

但是在之前分析的Webx的RPC执行流程中（我之前的文章Webx的执行流程），我们发现在RPCServiceHandlerImpl的handleRequest方法中会构建用于RPC的RequestContext

// 构建RequestContext
RPCRequestContext requestContext = this.createRequestContext(request, response, errorContext);

最终的执行的是构造函数：

public DefaultRPCRequestContext(HttpServletRequest request, HttpServletResponse response,
                                List<RPCInvokeInterceptor> globalInterceptors,
                                List<PropertyFilter> globalValueFilters, ErrorContext errorContext,
                                boolean productionMode, XssType xssType) {
    this.request = request;
    this.response = response;

    this.globalInterceptors = globalInterceptors;
    this.globalValueFilters = globalValueFilters;

    this.url = request.getRequestURI();
    String contextPath = request.getContextPath();
    int length = contextPath.length();

    if (length > 0) { // 截取contextPath
        this.url = this.url.substring(length);
    }

    int index = this.url.lastIndexOf(".");
    if (index != -1) {
        this.url = this.url.substring(0, index);
    }

    this.errorContext = errorContext;
    this.productionMode = productionMode;
    this.xssType = xssType;
}

问题就出现在了这一步this.url = request.getRequestURI()

那么我们先看看webx对request做的包装。

在执行内部跳转的时候会执行RewriteRequestContextImpl中的

RequestWrapper requestWrapper = new RequestWrapper(wrappedRequest);

requestWrapper.setPath(path);

setRequest(requestWrapper);

我们看一下这个类

private class RequestWrapper extends AbstractRequestWrapper {
    private       String  path;
    private final boolean prefixMapping;
    private final String  originalServletPath;

    public RequestWrapper(HttpServletRequest request) {
        super(RewriteRequestContextImpl.this, request);

        // Servlet mapping有两种匹配方式：前缀匹配和后缀匹配。
        // 对于前缀匹配，例如：/turbine/aaa/bbb，servlet path为/turbine，path info为/aaa/bbb
        // 对于后缀匹配，例如：/aaa/bbb.html，servlet path为/aaa/bbb.html，path info为null
        this.prefixMapping = ServletUtil.isPrefixServletMapping(request);
        this.originalServletPath = request.getServletPath();
    }

    public void setPath(String path) {
        this.path = trimToNull(path);
    }

    @Override
    public String getServletPath() {
        if (path == null) {
            return super.getServletPath();
        } else {
            if (prefixMapping) {
                if (startsWithPath(originalServletPath, path)) {
                    return originalServletPath; // 保持原有的servletPath
                } else {
                    return "";
                }
            } else {
                return path;
            }
        }
    }

    @Override
    public String getPathInfo() {
        if (path == null) {
            return super.getPathInfo();
        } else {
            if (prefixMapping) {
                if (startsWithPath(originalServletPath, path)) {
                    return path.substring(originalServletPath.length()); // 除去servletPath后剩下的部分
                } else {
                    return path;
                }
            } else {
                return null;
            }
        }
    }
}

使用了装饰着模式继续对RequestContext进行了包装，并将需要跳转的url设置为path，原有的url为originalServletPath。同时我们也看到了RequestWrapper其本身也是继承了HttpServletRequest，同时重写了getServletPath()和getPathInfo()方法，以获得需要跳转的url的servletPath和pathInfo

那么也就是说我们在后面获得需要跳转的url时不能再使用这样的方法，this.url = request.getRequestURI()因为这其中HttpServletRequest的本质还是指向原来url的，我们需要使用ServletUtil.getResourcePath

public static String getResourcePath(HttpServletRequest request) {
    String pathInfo = normalizeAbsolutePath(request.getPathInfo(), false);
    String servletPath = normalizeAbsolutePath(request.getServletPath(), pathInfo.length() != 0);

    return servletPath + pathInfo;
}

这样结合RequestWrapper覆盖的方法就能够获得需要跳转的url的信息。相信webx的开发人员是忘记了这一点。

接下来呢？

联系Webx的人员，跟他们说你们有bug，这样还是存在一定的延误，或许下个版本他们就会修复，但实际是他们不再对RPC进行维护。那我们怎么办？很简单，直接写一个同类名相同的类，然后改写其中流程

this.url = ServletUtil.getResourcePath(request);
//this.url = request.getRequestURI();

再启动tomcat就ok了！

Tomcat ClassLoader

链接：https://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html

也就是Tomcat会首先加载我们项目中的class，然后再去加载第三方jar，搞定！

还有哪些问题？

Webx在url中都没有考虑contextPath，当然我们的Tomcat都是一个Tomcat容器单一应用的，也就不会出现问题，但是这毕竟是一个隐患，很有可能深深地坑一批童鞋

参考：http://tomcat.apache.org/tomcat-7.0-doc/config/context.html