我有一个URL缩短应用程序（类似于tinyurl.com，bit.ly等），它也会重定向到file：// URL。
在内部，这是一个基于Servlet的网络应用程序，我所做的就是检索targetURL并从服务器端执行response.sendRedirect(targetURL)。
这也适用于file://个网址。但是，最近，这已停止在Chrome上运行。当我尝试重定向到file://foo.txt时（通过response.sendRedirect('file://foo.txt')，事情就会失败（Chrome调试器会说“已取消”）。
答案 0 :(得分：1)
我说这是一个坏主意，我很高兴至少Chrome否认这一点（尽管我怀疑其他浏览器也会这样）。如果您可以指示其他人的浏览器打开任意文件，那将是一个相当大的安全漏洞。
第二，你为什么要这样做？它要求用户在其计算机上的同一位置实际拥有相同的文件。看起来像一个非常狭窄的用例。我使用bit.ly测试了您的用例，并且您尝试在那里添加file:///网址，它被视为无效网址，无法缩短。
编辑：有一个非常好的答案涵盖同一主题here。它引用了有关security restrictions with redirection的有用资源。
您还指定这适用于内部应用。如果您正在尝试进行某种文档共享，我会说您应该考虑使用专用系统。另一个选择是使用“dropbox light”扩展您的服务，您的用户可以将相关文件上传到存储服务，并且您可以基于通过常规http / https从存储中提供文件来生成缩短的URL。 / p>