跟踪源码来分析一个 empty file=404 的坑， WebFlux 我要鲨了你呀！

SpringCloudGateway 这东西在现在市面上用的还是不多的，毕竟这框架基于 WebFlux，而WebFlux是 Reactor 模式的架构， 和一般 Java 开发人形成的开发逻辑不太能匹配上， 学习曲线就比较陡峭。

可惜我就偏偏在使用到 SpringCloudGateway  这玩意的时候遇到了个坑， 并且还从Google搜到百度， 从官方文档看到StackOverflow，  都没一个人提到。指不定还有什么其他的坑没被人发现。 在没资料的情况下遇到问题大半只能靠自己看源码了， 最终发现其实和 Spring Cloud Gateway 关系不大,  完全是 WebFlux 的锅。下面就针对我遇到的问题结合其源码来走一道分析流程， 定位问题所在。

环境

• org.springframework.cloud:spring-cloud-starter-gateway:3.0.0

问题描述

这是我在使用 Spring Cloud Gateway 配置静态资源映射时遇到的问题

按照常规配置方法， 网关嘛， 做个路径模板和资源目录的映射就行了， 基本代码如下:

@Bean
public RouterFunction<ServerResponse> staticResourceLocator(ResourceLoader resourceLoader) {
    if (prop.getResourceMapping().isEmpty()) return null;
​
    RouterFunctions.Builder builder = RouterFunctions.route();
​
    prop.getResourceMapping().forEach((key, value) -> {
        logger.info("添加静态资源映射配置: [{}] -> [{}]", key, value);
        builder.add(RouterFunctions.resources(key, resourceLoader.getResource(value)));
    });
​
    return builder.build();
}

单纯做个路径映射的反代而已， 将指定路径映射到另外的路径，这是作为网关最基本的需求，各项指标正常是应该的。

可是在某些 特殊情况 下,   你使用 Spring Cloud Gateway 会产生让你意想不到的事情  ( 实际上是 WebFlux 的 API 导致的 )。

那就是我遇到的这种情况:

• 获取 为空的( != null )静态文件 , 文件本身 存在 ， 但实际上里边没有内容 (长度为零)。 反向代理到这种资源会直接返回 404 状态码。

正常的话应该是返回一个 Content-length:  0 的200响应才对,  因为这文件真的存在啊。

无论是直接访问也好，传到阿里云OSS访问也好， 用Nginx在前面代理一层也好，都是我说的这种逻辑。 偏偏SpringCloudGateway 给你整个 404。 我也是不知道该怎么吐槽了。  这已经无法用 feature 来解释了， 我认为这是不合理的。

但在没有资料的情况下还能怎么办呢， 我又想解决这个问题，因为这个情况已经给业务带来了影响，  那我就只能从源码入手了。

前置提示

本片文章为记录向， 不会有名词解释&概念解释。 比如一些 SpringFramework 的相关知识点， 还有 Mono、 Flux 之类和 Reactor 相关的东西。

由于涉及到源码， 还是这种反应式的，会出现一大堆的链式调用。  可能对知识体系不够完善的同学不是很友好…

下面正式开始跟踪流程。

具体分析

我们首先需要确定的是:  请求在网关的哪个部分中断了?

相信熟悉 Spring MVC 架构的同学们应该会清楚 SpringMVC 有个叫 DispatcherServlet 的统一入口存在， 对于 WebFlux 也是一样的， 不过 WebFlux 的入口叫 DispatcherHandler.

DispatcherHandler#handle 方法为 WebFlux 的请求入口, 下面是源码:

    @Override
    public Mono<Void> handle(ServerWebExchange exchange) {
        if (this.handlerMappings == null) {
            return createNotFoundError();
        }
        return Flux.fromIterable(this.handlerMappings)
                .concatMap(mapping -> mapping.getHandler(exchange))
                .next()
                .switchIfEmpty(createNotFoundError())
                .flatMap(handler -> invokeHandler(exchange, handler))
                .flatMap(result -> handleResult(exchange, result));
    }

这里我根据断点后得知了情报: handlerMappings 没有映射到, 所以走了 switchIfEmpty 逻辑, 抛出了 404 错误 (但路径实际上是匹配的, 文件也真实存在)

既然知道了是因为 handlerMappings 没有匹配到,   那就是说所有的 handlerMappings 都遍历了一次,  全部返回的是 Empty Mono. 

我们来看下 getHandler 方法源码。 获取静态资源的话， 实际上就是返回一个能获取资源的处理器，最终是委托给了抽象方法 getHandlerInternal () 由子类来实现， 典型的模板方法模式。

    @Override
    public Mono<Object> getHandler(ServerWebExchange exchange) {
        return getHandlerInternal(exchange).map(handler -> {
            if (logger.isDebugEnabled()) {
                logger.debug(exchange.getLogPrefix() + "Mapped to " + handler);
            }
            ServerHttpRequest request = exchange.getRequest();
            if (hasCorsConfigurationSource(handler) || CorsUtils.isPreFlightRequest(request)) {
                CorsConfiguration config = (this.corsConfigurationSource != null ? this.corsConfigurationSource.getCorsConfiguration(exchange) : null);
                CorsConfiguration handlerConfig = getCorsConfiguration(handler, exchange);
                config = (config != null ? config.combine(handlerConfig) : handlerConfig);
                if (config != null) {
                    config.validateAllowCredentials();
                }
                if (!this.corsProcessor.process(config, exchange) || CorsUtils.isPreFlightRequest(request)) {
                    return REQUEST_HANDLED_HANDLER;
                }
            }
            return handler;
        });
    }
​
    //由子类实现的方法,  获取实际的处理器
    protected abstract Mono<?> getHandlerInternal(ServerWebExchange exchange);

根据我断点看的信息，有一个叫做 RouterFunctionMapping  的对象匹配我创建的静态资源路径映射。那么就是说实际上对于我指定的路径的请求， 都会经过 RouterFunctionMapping 此实例。 并且由于我的路径映射是正确的，因为其他的资源均可以正常访问， 只有空文件返回了404而已，  所以问题肯定就出在这里。

看其源码,  他继承了AbstractHandlerMapping, 实现了 getHandlerInternal 方法来提供一个处理器

@Override
protected Mono<?> getHandlerInternal(ServerWebExchange exchange) {
    if (this.routerFunction != null) {
        ServerRequest request = ServerRequest.create(exchange, this.messageReaders);
        return this.routerFunction.route(request)  //就是这里返回的了 Empty Mono
                .doOnNext(handler -> setAttributes(exchange.getAttributes(), request, handler));
    }
    else {
        return Mono.empty();
    }
}

RouterFunctionMapping  内部维护了一个 RouterFunction 类, 最终走的就是这个 RouterFunction 的route() 方法逻辑。route方法会返回一个 Mono<HandlerFunction<T>> 即一个处理器,  可以通过 ServletRequest 获取指定的响应。

这个类其实就是在配置里使用 RouterFunctions#resources 创建的类,  可以回到最顶上看资源配置的地方。

那么这里就需要点进 RouterFunctions 的源码，看看他这个 resources()  到底是返回了个什么东西

可以很轻松通过其源码得知:   创建时调用 RouterFunctions.resources(String, Resource) 首先通过 resourceLookupFunction()  创建出了一个 PathResourceLookupFunction 对象

public static RouterFunction<ServerResponse> resources(String pattern, Resource location) {
    return resources(resourceLookupFunction(pattern, location));
}
​
//得到了这个 PathResourceLookupFunction 对象
public static Function<ServerRequest, Mono<Resource>> resourceLookupFunction(String pattern, Resource location) {
    return new PathResourceLookupFunction(pattern, location);
}

然后将得到的 PathResourceLookupFunction  传入方法 resources,  创建出了 ResourcesRouterFunction 对象返回。

public static RouterFunction<ServerResponse> resources(Function<ServerRequest, Mono<Resource>> lookupFunction) {
 return new ResourcesRouterFunction(lookupFunction);
}

ResourcesRouterFunction 是 RouterFunctions 的一个内部类，RouterFunctions.resources 方法就是将他创建并返回给了我们。  而他,  就是 RouterFunctionMapping 里边维护的 routeFunction 了, 也是一切的元凶。所以我们来看看他的源码:

private static class ResourcesRouterFunction extends  AbstractRouterFunction<ServerResponse> {
​
    private final Function<ServerRequest, Mono<Resource>> lookupFunction;
​
    public ResourcesRouterFunction(Function<ServerRequest, Mono<Resource>> lookupFunction) {
        Assert.notNull(lookupFunction, "Function must not be null");
        this.lookupFunction = lookupFunction;
    }
​
    @Override
    public Mono<HandlerFunction<ServerResponse>> route(ServerRequest request) {
        //lookupFunction 就是 PathResourceLookupFunction
        return this.lookupFunction.apply(request).map(ResourceHandlerFunction::new);
    }
​
    @Override
    public void accept(Visitor visitor) {
        visitor.resources(this.lookupFunction);
    }
}

这个源码很好懂， 使用到了上面提到了的 PathResourceLookupFunction。而调用 PathResourceLookupFunction#apply  返回的是一个 Mono<Resource> 对象。 也就是我们需要的静态资源对象。至于之后创建的 ResourceHandlerFunction 就不用管了。 我看了他的源码，这个是用来将 Resource 封装成 ServerResponse 的, 根据其内部逻辑， GET 请求是不会返回空Mono的， 有兴趣的可以自己去看， 这里就不贴代码占篇幅了 。

至此。 已经定位到了整条逻辑链最底层的地方了，也就是获取 Resource 的地方。 现在我们只要知道为什么在 PathResourceLookupFunction 这个类上调用 apply() 方法， 会返回一个空的 Mono 对象就行了。

好的这里深入进去：

@Override
public Mono<Resource> apply(ServerRequest request) {
    PathContainer pathContainer = request.requestPath().pathWithinApplication();
    if (!this.pattern.matches(pathContainer)) {
        return Mono.empty();
    }
​
    pathContainer = this.pattern.extractPathWithinPattern(pathContainer);
    String path = processPath(pathContainer.value());
    if (path.contains("%")) {
        path = StringUtils.uriDecode(path, StandardCharsets.UTF_8);
    }
    if (!StringUtils.hasLength(path) || isInvalidPath(path)) {
        return Mono.empty();
    }
    
    //上边都是对路径做校验和处理,  由于我的路径没有问题， 所以必定会走到这
    try {
        //这儿已经创建出了含有资源完整路径的 Resource 实体
        Resource resource = this.location.createRelative(path);
        //  特异点！ 
        if (resource.exists() && resource.isReadable() && isResourceUnderLocation(resource)) {
            return Mono.just(resource);
        }
        else {
            return Mono.empty();
        }
    }
    catch (IOException ex) {
        throw new UncheckedIOException(ex);
    }
}

好吧， 到这儿魔法已经解开了。 即上边代码中的特异点。

就是因为这三个判定中有一个返回了false,  导致最终整个方法返回了 Empty Mono。

到这整个分析流程也就差不多了，  根据我去一个个方法的源码进行阅读来看。最终发现是 isReadable 方法会在这种情况(空文件)下返回 false 。

isReadable  定义在 AbstractFileResolvingResource 上

@Override
public boolean isReadable() {
    try {
        URL url = getURL();
        if (ResourceUtils.isFileURL(url)) {
            // Proceed with file system resolution
            File file = getFile();
            return (file.canRead() && !file.isDirectory());
        }
        else {
            // Try InputStream resolution for jar resources
            URLConnection con = url.openConnection();
            customizeConnection(con);
            if (con instanceof HttpURLConnection) {
                HttpURLConnection httpCon = (HttpURLConnection) con;
                int code = httpCon.getResponseCode();
                if (code != HttpURLConnection.HTTP_OK) {
                    httpCon.disconnect();
                    return false;
                }
            }
            long contentLength = con.getContentLengthLong();
            if (contentLength > 0) {
                return true;
            }
            //  重点！！！！
            else if (contentLength == 0) {
                // Empty file or directory -> not considered readable...
                return false;
            }
            else {
                // Fall back to stream existence: can we open the stream?
                getInputStream().close();
                return true;
            }
        }
    }
    catch (IOException ex) {
        return false;
    }
}

结论

就是因为 AbstractFileResolvingResource#isReadable 返回了 false 导致的 PathResourceLookupFunction#apply 判定失败, 从而返回了 Empty Mono。 最终Empty Mono 从调用栈中一直传到顶层 DispatcherHandler ,  走了 switchIfEmpty 逻辑,  从而返回404。

如果根据 isReadable  方法中的注释  “Empty file or directory -> not considered readable…” 来看，   Resource 的逻辑是没问题的。 那么我将这个问题归根给 PathResourceLookupFunction 的 apply 方法。

所以说， 我真的是佛了。 魔法虽然是解开了， 可我此时只剩下一头雾水。

空文件是不可读。  但是这里对这个点做判定是我完全无法理解的。  作为一个路径映射, 明明文件存在 ，仅因为其不可读， 就返回 404 ( 文件不存在 )， 这怎么想都很奇怪啊？？？

填坑

毕竟源码我们也不能动， 如果要填这个坑的话， 我们就需要自己定义一个  Function<ServerRequest, Mono<Resource>>  来将一个 ServerRequest 转化为我们需要的 Resource。

因为 RouteFunctions 提供了相应的接口:

public static RouterFunction<ServerResponse> resources(Function<ServerRequest, Mono<Resource>> lookupFunction) {
 return new ResourcesRouterFunction(lookupFunction);
}

我们只需要在进行资源配置的时候使用此方法即可。就直接传入我们自定义的 Function 对象。

这个对象呢， 因为逻辑实际上和 PathResourceLookupFunction 是一样的，  所以直接将其整个源码复制过来， 然后对其进行微调。

我就是这么干的，  最终果不其然完美解决了空文件返回404的问题。

已经可以成功的返回 Content-Length: 0 的 200 状态码响应。具体的代码就不贴了。