优化ZFile直接链接生成

[qeqeq1]

描述

请求功能增加：直接返回存储桶绑定域名形式的链接和允许 /directlink 为空

背景

当前 ZFile 生成的直接链接，实际上是一个 302 跳转链接，而非真正的“直链”。 用户首次访问仍需要 ZFile 作出跳转，这在某些情况下会影响文件的可靠性。 我十分理解此举是为了记录访问情况、控制访问权限、限制访问速度、提供始终有效的链接（一些后端服务的链接往往失效很快，到期必须重新生成） 但在未启用签名、控制文件访问权限和记录日志、文件存储为S3存储桶时，复制的“直链”仍是302跳转链接，似乎并不优雅。 希望能够直接返回存储桶绑定域名形式的链接的选项，以便在 ZFile 所在服务器出现问题时，文件服务不受中断

需求

1. 直接返回存储桶绑定域名形式的链接：

   • 希望在未启用签名、不需要控制文件访问权限和记录日志时，增加一个选项以直接返回存储桶绑定域名形式的链接。这将保证文件访问的可靠性，即使 ZFile 服务器出现问题，文件仍由 S3 存储桶直接提供。

2. 允许 /directlink 设置为空：

   • 当前直接连接格式为 http(s)://example.com/directlink/path/filename。希望能够增加一个选项，让 /directlink 设置为空，这样可以直接从 http(s)://ip:port/path/filename 请求文件，与浏览器前端访问页面风格一致。

如，用户访问 example.com/mydisk时，看见该目录存在：1.png 2.png 3.png等文件，其直接在浏览器地址栏输入example.com/mydisk/1.png 显然更符合直觉。 而生成一个直链，只是为了在链接中加上一个/directlink，（zfile的”直链“仍然是path/filename的文件列表风格，还不是网盘系统常见的文件id风格，既然是目录列表风格，不能通过domain/path/filename直接访问文件，似乎没有必要。

当然，我深知作者如此设计可能是为了更好兼容多种使用场景，但对于上传后文件链接固定、文件目录结构固定的存储桶类存储，在不进行权限管理、频率限制等日常简单使用的情况下，此限制似乎意义不大

结论

希望能在 ZFile 中增加这些功能，以提高文件访问的可靠性和用户体验。谢谢！

额外信息

此外，https://issue.zfile.vip/ 在提交bug类型issue后，点击功能建议按钮，填写完内容，点击预览，预览内容仍为第一次的填写的bug反馈 issue，但导出到github正常

[zhaojun1998]

1. 这个适用场景太少，几乎没人会关闭访问权限，日志，且文件本身链接永久有效，这是及其不安全的（不仅对 ZFile 不安全，存储源不开启签名访问也非常不安全，很容易被刷流量带来财产损失），对于这样一个前置条件苛刻，且行为不安全的功能，我目前持保留态度，暂不打算开发支持。
2. 直链前缀这个你可以改个短点的，目前这样设计主要是为了快速区分到底是访问的页面还是直链。如访问 http://example.com/video/1.mp4 ，怎么确认这是一个名为 1.mp4 的文件还是文件夹，真要确认的话，我得先查询存储源这个目录下是否有这个文件，然后再决定返回页面还是直链，这会在每次访问直链带来额外的性能损耗，且逻辑更复杂，得不偿失。
3. issue.zfile.vip 这个会修复。

[zhaojun1998]

补充：对于场景 1，我想了下，可以在文件右键菜单增加一个 "复制下载链接" 的功能，复制的是存储源原始的链接，页面会提示该链接不会保证时效、无法记录下载日志，无法校验权限。

[qeqeq1]

补充：对于场景 1，我想了下，可以在文件右键菜单增加一个 "复制下载链接" 的功能，复制的是存储源原始的链接，页面会提示该链接不会保证时效、无法记录下载日志，无法校验权限。

十分赞同 期待下次更新