我有一个 URL 缩短器应用程序（类似于 tinyurl.com、bit.ly 等），它也重定向到 file:// URL。
在内部，这是一个基于 Servlet 的 web 应用程序，我所做的就是从服务器端检索targetURL并执行一个。response.sendRedirect(targetURL)
这也适用于file://URL。但是，最近，这已停止在 Chrome 上运行。当我尝试重定向到file://foo.txt（通过 aresponse.sendRedirect('file://foo.txt')时，事情只是失败了（Chrome 调试器显示“已取消”）。
然而，在 FF 和 IE 中一切正常。有什么线索吗？
我会说这是一个坏主意，我很高兴至少 chrome 否认了这一点（尽管我怀疑其他浏览器也会这样做）。如果您可以指示其他人的浏览器打开任意文件，那将是一个相当大的安全漏洞。
其次，你为什么要这样做？这将要求用户在其计算机上的相同位置实际拥有相同的文件。似乎是一个非常狭窄的用例。我用 bit.ly 测试了你的用例，如果你尝试在file:///那里添加一个 url，它被认为是一个无效的 URL，不能被缩短。
编辑：这里有一个很好的答案，涵盖了相同的主题。它引用了这个关于重定向安全限制的有用资源。
您还指定这是针对内部应用程序的。如果您尝试进行某种文档共享，我会说您应该为此研究专用系统。另一种选择是使用“保管箱灯”扩展您的服务，您的用户可以在其中将相关文件上传到存储服务，并且您可以根据通过常规 http/https 从存储中提供文件来生成缩短的 url。