文章从零手写实现 nginx-29-try_files 指令分享给大家，欢迎收藏Java资料网，专注分享技术知识

前言

大家好，我是老马。很高兴遇到你。

我们为 java 开发者实现了 java 版本的 nginx

https://github.com/houbb/nginx4j

如果你想知道 servlet 如何处理的，可以参考我的另一个项目：

手写从零实现简易版 tomcat minicat

手写 nginx 系列

如果你对 nginx 原理感兴趣，可以阅读：

从零手写实现 nginx-01-为什么不能有 java 版本的 nginx?

从零手写实现 nginx-02-nginx 的核心能力

从零手写实现 nginx-03-nginx 基于 Netty 实现

从零手写实现 nginx-04-基于 netty http 出入参优化处理

从零手写实现 nginx-05-MIME类型（Multipurpose Internet Mail Extensions，多用途互联网邮件扩展类型）

从零手写实现 nginx-06-文件夹自动索引

从零手写实现 nginx-07-大文件下载

从零手写实现 nginx-08-范围查询

从零手写实现 nginx-09-文件压缩

从零手写实现 nginx-10-sendfile 零拷贝

从零手写实现 nginx-11-file+range 合并

从零手写实现 nginx-12-keep-alive 连接复用

从零手写实现 nginx-13-nginx.conf 配置文件介绍

从零手写实现 nginx-14-nginx.conf 和 hocon 格式有关系吗？

从零手写实现 nginx-15-nginx.conf 如何通过 java 解析处理？

从零手写实现 nginx-16-nginx 支持配置多个 server

从零手写实现 nginx-17-nginx 默认配置优化

从零手写实现 nginx-18-nginx 请求头+响应头操作

从零手写实现 nginx-19-nginx cors

从零手写实现 nginx-20-nginx 占位符 placeholder

从零手写实现 nginx-21-nginx modules 模块信息概览

从零手写实现 nginx-22-nginx modules 分模块加载优化

从零手写实现 nginx-23-nginx cookie 的操作处理

从零手写实现 nginx-24-nginx IF 指令

从零手写实现 nginx-25-nginx map 指令

从零手写实现 nginx-26-nginx rewrite 指令

从零手写实现 nginx-27-nginx return 指令

从零手写实现 nginx-28-nginx error_pages 指令

从零手写实现 nginx-29-nginx try_files 指令

nginx try_files 指令是什么？

Nginx 的 try_files 指令用于尝试一个或多个文件路径或 URI，以处理客户端请求。如果找到一个文件或 URI 存在，则返回该文件或执行该 URI。如果没有找到，则返回一个指定的错误码或重定向到一个默认的处理程序。try_files 指令通常用于静态文件服务、动态内容处理和错误处理。

语法

try_files file1 [file2 ... filen] uri|=code;

• file1, file2, ... filen: 依次检查这些文件或目录的存在性。
• uri: 如果前面的文件或目录都不存在，重定向到指定的 URI。
• =code: 如果前面的文件或目录都不存在，返回指定的 HTTP 状态码。

示例

静态文件服务

优先返回静态文件，如果文件不存在，则返回 404 错误。

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

动态内容处理

优先返回静态文件，如果文件不存在，则将请求重定向到一个 PHP 处理程序。

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        root /var/www/html;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

单页应用（SPA）

所有路径都指向入口的 index.html 文件，以支持前端路由。

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        try_files $uri $uri/ /index.html;
    }
}

工作原理

1. 尝试多个文件路径：按顺序检查指定的文件或目录是否存在。如果找到一个存在的文件或目录，则立即返回该文件或目录。
2. 重定向到 URI：如果所有指定的文件或目录都不存在，则重定向到一个指定的 URI。这通常用于将请求传递给动态处理程序。
3. 返回指定的 HTTP 状态码：如果所有指定的文件或目录都不存在，并且未指定 URI，则返回指定的 HTTP 状态码（如 404）。

优点

• 灵活性高：可以轻松处理静态文件、动态内容和错误处理。
• 配置简洁：通过一条指令即可实现多种路径检查和处理逻辑。
• 性能优化：优先处理静态文件，避免不必要的动态处理，提高响应速度。

缺点

• 调试困难：由于会依次检查多个路径，调试和排查问题时可能比较复杂。
• 灵活性有限：无法进行条件判断或复杂的重写规则处理，需要结合其他指令使用。
• 错误处理简单：只能指定简单的错误处理方式，无法进行复杂的错误处理逻辑。

总结

Nginx 的 try_files 指令是一种非常强大和灵活的工具，适用于处理多种请求路径和文件检查需求。

通过适当的配置，可以显著提高服务器的性能和响应速度，同时简化配置文件的编写和维护。

java 实现

整体思路

1）遍历非最后一个的 uri，替换占位符，判断文件是否存在，存在则返回。

2）判断最后一个 uri 或者 code，直接处理对应的逻辑。

核心逻辑

/**
 * try_files path1 path2 ... final;
 *
 * - `path1`, `path2`, ...：要检查的文件或 URI 列表。可以是相对路径或绝对路径。
 *
 * - `final`：如果前面的所有路径都不存在，最后一个参数可以是一个 URI，Nginx 将内部重定向到该 URI，或者是一个 HTTP 状态码（如 404），用于返回相应的错误。
 *
 * @see INginxPlaceholder 占位符
 * @see com.github.houbb.nginx4j.support.request.dispatch.http.NginxRequestDispatchHttpReturn 设置对应的返回码 =xxx
 */
public class NginxTryFilesDefault implements INginxTryFiles{

    private static final Log log = LogFactory.getLog(NginxTryFilesDefault.class);

    /**
     * 处理 try_files 指令
     *
     * @param request     请求
     * @param nginxConfig 配置
     * @param context     上下文
     */
    public void tryFiles(FullHttpRequest request,
                         final NginxConfig nginxConfig,
                         NginxRequestDispatchContext context) {
        // 获取当前的 location
        List<NginxCommonConfigEntry> directiveList = InnerNginxContextUtil.getLocationDirectives(context);
        Map<String, List<NginxCommonConfigEntry>> directiveMap = InnerNginxContextUtil.getLocationDirectiveMap(directiveList);

        List<NginxCommonConfigEntry> tryFiles = directiveMap.get(NginxDirectiveEnum.TRY_FILES.getCode());
        if(CollectionUtil.isEmpty(tryFiles)) {
            return;
        }

        NginxCommonConfigEntry firstEntry = tryFiles.get(0);

        // 遍历非 final 的文件信息
        String notFinalUri = getNotFinalMatchedFileUri(firstEntry, context);
        if(StringUtil.isNotEmpty(notFinalUri)) {
            request.setUri(notFinalUri);
            return;
        }

        // 判断 final 变量
        final String lastUri = firstEntry.getValues().get(firstEntry.getValues().size()-1);
        if(lastUri.startsWith("=")) {
            // 拆分为 return
            NginxReturnResult result = new NginxReturnResult();
            result.setCode(Integer.parseInt(lastUri.substring(1)));
            result.setValue("try_files final");
            context.setNginxReturnResult(result);
            return;
        }

        String lastReplaceUri = replacePlaceholders(lastUri, context.getPlaceholderMap());
        request.setUri(lastReplaceUri);
    }

    /**
     * 获取匹配的文件 url
     * @param entry 实体
     * @param context 上下文
     * @return 结果
     */
    private String getNotFinalMatchedFileUri(final NginxCommonConfigEntry entry,
                                            NginxRequestDispatchContext context) {
        List<String> values = entry.getValues();

        for(int i = 0; i < values.size()-1; i++) {
            String replacedUri = getMatchedFileUri(values.get(i), context);

            if(StringUtil.isNotEmpty(replacedUri)) {
                return replacedUri;
            }
        }

        return null;
    }

    private String getMatchedFileUri(final String requestUri,
                                     NginxRequestDispatchContext context) {
        final Map<String, Object> replaceMap = context.getPlaceholderMap();

        String replacedUri = replacePlaceholders(requestUri, replaceMap);

        // 判断文件是否存
        File file = InnerFileUtil.getTargetFile(replacedUri, context);
        if(file.exists()) {
            log.info("Nginx getMatchedFileUri file={}", file.getAbsolutePath());
            return replacedUri;
        }

    return null;
    }

    /**
     * 替换字符串中的占位符
     *
     * @param input    用户输入的字符串，包含占位符
     * @param variables 存储占位符及其替换值的 Map
     * @return 替换后的字符串
     */
    public static String replacePlaceholders(String input, Map<String, Object> variables) {
        // 使用 StringBuilder 来构建替换后的字符串
        StringBuilder result = new StringBuilder(input);

        // 遍历 Map 进行替换
        for (Map.Entry<String, Object> entry : variables.entrySet()) {
            String placeholder = entry.getKey();
            String replacement = String.valueOf(entry.getValue());

            // 使用 String 的 replace 方法替换所有占位符
            int start = result.indexOf(placeholder);
            while (start != -1) {
                result.replace(start, start + placeholder.length(), replacement);
                start = result.indexOf(placeholder, start + replacement.length());
            }
        }

        return result.toString();
    }

}

小结

Nginx 的 try_files 指令是一个强大且灵活的工具，用于处理静态文件、友好 URL 重写和自定义错误处理。

它通过按顺序检查多个路径并执行相应操作，使配置文件更加简洁和高效。

主要用途

• 静态文件服务：首先尝试提供静态文件，如果找不到则执行其他操作。
• 友好 URL 重写：用于支持伪静态 URL，将请求重写到实际的文件路径或动态脚本。
• 错误处理：如果所有尝试的文件都不存在，则返回一个特定的错误页面。

工作机制

• try_files 按顺序检查列出的每个路径。
• 如果找到了一个存在的文件或目录，则立即停止进一步检查并使用该文件或目录响应请求。
• 如果所有列出的路径都不存在，则执行最后指定的 URI，这通常是一个错误页面或其他处理逻辑。

优点

• 高效静态文件处理：减少了不必要的动态请求处理。
• 灵活的错误处理：可以轻松配置自定义错误页面或重写规则。
• 简洁配置：使复杂的文件查找和重写逻辑更加直观和易于管理。

文章来源:https://www.cnblogs.com/houbbBlogs/p/18306285
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！