重写URL以影响“另存为"文档名称 [英] rewrite URL to affect "save as" filename

问题描述

我的应用程序在JSP/Struts中，并在WebSphere上运行.我无权访问服务器/really/，因此我试图从应用程序本身(Struts操作和配置，JSP等)中完成所有操作.

My application is in JSP/Struts and running on WebSphere. I don't have access to the server /really/ so I'm trying to do all this from within the app itself (Struts actions & config, JSP, etc).

我有一个页面，显示用户可能要查看的PDF文档的链接.当他们单击链接时，它将转发到文档视图" STRUTS操作，该操作执行从后端系统检索PDF的工作，然后在浏览器窗口中显示PDF.一切正常.

I have a page that displays links for PDF documents that the user might want to look at. When they click on the link, it is forwarded to the 'document view' STRUTS action which performs the work to retrieve the PDF from the back-end system and then displays the PDF in the browser window. This all works fine.

用户要求在转到文件"->另存为..."时为每个文档自定义文档的文件名，但现在浏览器希望尝试以我的Struts名称命名该文档行动.示例:"documentView.pdf"

The users have asked to have the file name of the document be customized for each document when they go to File->Save As... but right now the browser wants to try to name the document after the name of my Struts action. Example: "documentView.pdf"

我将要使用的文件名转发给STRUTS操作，我尝试使用"Content-Disposition"标头进行设置，但无法使其正常工作.实际上，如果我使用"attachment; filename ="myfilename"，它会很好用，但是它会立即强制执行另存为..."对话框，我也不想这样做.

I have the filename I want to use forwarded to the STRUTS action and I tried using the "Content-Disposition" header to set this, but haven't been able to get it to work. Actually it works great if I use "attachment; filename="myfilename" " but then it FORCES the "Save As..." dialog straight away, which I don't want either.

如果我愿意，我希望能够在浏览器窗口中查看PDF内联并以自定义文件名保存.

I want to be able to look at the PDF inline in the browser window and save it with a custom filename if I so choose.

我已经读到，URL重写可能是可行的，但是我在梳理此技术的工作方式时遇到了麻烦.

I have read that this might be possible to do with URL rewriting but I'm having trouble sorting out how this technique might work.

任何想法都将不胜感激.

Any ideas will be greatly appreciated.

推荐答案

将Content-Disposition的附件"部分更改为内联".

Change the "attachment" part of the Content-Disposition to "inline".

浏览器对Content-Disposition的支持不稳定.

Browser support for Content-Disposition is flaky.

在被支持之前，您曾经能够通过在URL末尾放置多余的键/值来使浏览器执行正确的操作.喜欢:

Before it was supported, you used to be able to get the browser to do the right thing by putting a superfluous key/value at the end of the URL. Like:

http://example.com/getPDF?id=123213&filename=mydoc.pdf

某些浏览器选择URL的最后一位作为文件名.不知道这是否仍然有效.

Some browsers picked up the last bit of the URL as the filename. Not sure if that still works.

这篇关于重写URL以影响“另存为"文档名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！