☰

nginx，重写删除文件扩展名后错误的 MIME 类型

tag-icon • tag-icon nginx rewrite mime
nginx，重写删除文件扩展名后错误的 MIME 类型

我有一个存储，其中存储的文件的文件名与其 MD5 哈希值相对应。文件存储如下：

...
/srv/storage/25/
/srv/storage/25/25D6D1AD130E4EB7D11F6AB48C09414E
...
/srv/storage/DF/
/srv/storage/DF/DF35407C5E433B5644538B41C957ABCE
...

额外的目录只是为了防止单个根目录大小膨胀。

这些文件有各种类型：文本文件、PDF 文件、XLS 文件，什么都有。我通过 Web 界面提供这些文件，该界面列出了链接到 HTTP 文件服务器的真实文件名。为了方便用户在适当的应用程序中从浏览器（Firefox）打开这些文件，Web 应用程序将文件扩展名附加到文件服务器 URL 中的 MD5 文件名，以便浏览器可以根据文件扩展名推断出适当的处理程序。因此，例如，report2017.pdfWeb 界面中的文件链接到

http://corp.biz/files/DF35407C5E433B5644538B41C957ABCE.pdf

借助下面定义的重写它将提供文件：

/srv/storage/DF/DF35407C5E433B5644538B41C957ABCE

我使用 Nginx 站点中的这个位置将 URL 重写为文件系统中的正确路径：

    location /files {
        root /srv/storage;
        rewrite '^/files/([0-9A-F]{2})([0-9A-F]{30}).*$' /$1/$1$2 break;
    }

太棒了！它起作用了。不过现在 Nginx 会Content-Type: application/octet-stream针对 下的任何 URL回复/files。有没有办法让 Nginx 在重写之前解析 MIME 类型？

问题是Content-Type: application/octet-stream，对于 PDF 文件，即使 URL 中的文件名以 结尾.pdf，Firefox 也会因为某种原因直接转到保存存档对话框，而不是让用户在 PDF 查看器中打开它。这种情况只发生在 PDF 文件类型设置为在 Firefox 中预览。

答案1

我只是为了好玩而尝试了这个并且它有效：

    location /files {
      root   /usr/share/nginx/html;
    }

    location ~ "^/files/([0-9a-fA-F]{2})([0-9a-fA-F]{30})(.*)$" {
        return 301 $scheme://$http_host/files/$1/$1$2$3;
    }

看起来你忘记包含第 3 部分 (ext)。这也应该有效：

    location /files {
      root   /usr/share/nginx/html;
      rewrite '^/files/([0-9a-fA-F]{2})([0-9a-fA-F]{30})(.*)$' /files/$1/$1$2$3 break;
    }

相关内容