When I use Office URI Scheme to open an excel file ms-excel:nft|u|https://link-to-file.com/very%20Unreadable%20File%20Identifier.xlsx?useThisFileName=file%20Name.xlsx
with content-disposition specified in the response
Content-Disposition: attachment; filename="file%20Name.xlsx"; filename*=UTF-8''file%20Name.xlsx
Excel opens the link and creates a file with the name very Unreadable File Identifier.xlsx.
But when I open https://link-to-file.com/very%20Unreadable%20File%20Identifier.xlsx?useThisFileName=file%20Name.xlsx, in any browser, it saves it with the name file Name.xlsx
Is there any way to make Office URI Schemes respect the content-disposition header or to tell to Office the name of a file in the URI?
(Current MSFT employee in Office here. On the team that owns this scenario)
Office does not honor Content-Disposition in the URI Scheme scenarios. Skimming wikipedia and RFCs it looks like it was a normal thing for MIME handling in 1995 and mentioned for HTTP in 1999 and becoming more formalized in 2011 (with globalization support which would have been crucial for the Office customer base). RFC 6266 also says that it is not part of HTTP/1.1. I don't know exactly when this URI scheme came about, but it would be between 1994 and 2002, but that predates me joining Microsoft and my current team. I might be missing quite a bit of history, I just skimmed the RFCs after being pointed to this question, trying to guess why this wasn't supported.
Plus the first party servers that Office owns did not have this scenario and so the original developers probably didn't consider this at all in that era. (Note 3xx redirects won't work as a workaround, because that also isn't honored in this scenario afaik.)
It's a good feature request. It creates a bit of a backwards compatibility problem because the server won't know if a modern Office client is going to open the link or if it is an older client. (Or if a third party Office client implementation is used.) So that gives me some hesitation on putting it at the top of my teams backlog. But the utility this gives for service side implementors, especially ones that are auto-generating content is clear. So consider your feature request heard, but I can't promise it will get implemented. My team will look for more feedback that this feature is desired in that prioritization.