Office URI 方案忽略内容处置答案

【问题标题】：Office URI Scheme ignores Content-DispositionOffice URI 方案忽略内容处置
【发布时间】：2021-06-12 21:07:04
【问题描述】：

当我使用Office URI Scheme打开一个excel文件ms-excel:nft|u|https://link-to-file.com/very%20Unreadable%20File%20Identifier.xlsx?useThisFileName=file%20Name.xlsx

在响应中指定内容处置 Content-Disposition: attachment; filename="file%20Name.xlsx"; filename*=UTF-8''file%20Name.xlsx

Excel 会打开链接并创建一个名为 very Unreadable File Identifier.xlsx 的文件。

但是当我在任何浏览器中打开https://link-to-file.com/very%20Unreadable%20File%20Identifier.xlsx?useThisFileName=file%20Name.xlsx 时，它会以名称file Name.xlsx 保存它

有没有办法让 Office URI 方案尊重内容处置标头或告诉 Office URI 中的文件名？

【问题讨论】：

标签： excel uri ms-office url-scheme

【解决方案1】：

（此处为 Office 的当前 MSFT 员工。在拥有此方案的团队中）

Office 不支持 URI 方案方案中的 Content-Disposition。略读 wikipedia 和 RFC，看起来这对于 1995 年的 MIME 处理是很正常的事情，并在 1999 年提到 HTTP，并在 2011 年变得更加正式（全球化支持对于 Office 客户群来说至关重要）。 RFC 6266 还说它不是 HTTP/1.1 的一部分。我不知道这个 URI 方案是什么时候出现的，但应该是在 1994 年到 2002 年之间，但那是在我加入微软和我现在的团队之前。我可能错过了相当多的历史，在被指出这个问题后，我只是浏览了 RFC，试图猜测为什么不支持它。

再加上 Office 拥有的第一方服务器没有这种情况，因此最初的开发人员在那个时代可能根本没有考虑到这一点。（注意 3xx 重定向不能作为一种解决方法，因为在这种情况下也不支持 afaik。）

这是一个很好的功能请求。它会产生一些向后兼容性问题，因为服务器不知道现代 Office 客户端是否要打开链接，或者它是否是旧客户端。（或者，如果使用了第三方 Office 客户端实现。）所以这让我有些犹豫是否将它放在我的团队积压的顶部。但这为服务端实现者提供的实用程序，尤其是那些自动生成内容的实现者是很清楚的。因此，请考虑听到您的功能请求，但我不能保证它会得到实施。我的团队将寻求更多反馈，表明该功能在该优先级中是需要的。

【讨论】：

谢谢彼得的描述性回答。