"name" web pdf for better default save filename in Acrobat?

My app generates PDFs for user consumption. The "Content-Disposition" http header is set as mentioned here. This is set to "inline; filename=foo.pdf", which should be enough for Acrobat to give "foo.pdf" as the filename when saving the pdf.

However, upon clicking the "Save" button in the browser-embedded Acrobat, the default name to save is not that filename but instead the URL with slashes changed to underscores. Huge and ugly. Is there a way to affect this default filename in Adobe?

There IS a query string in the URLs, and this is non-negotiable. This may be significant, but adding a "&foo=/title.pdf" to the end of the URL doesn't affect the default filename.

Update 2: I've tried both

content-disposition  inline; filename=foo.pdf
Content-Type         application/pdf; filename=foo.pdf

and

content-disposition  inline; filename=foo.pdf
Content-Type         application/pdf; name=foo.pdf

(as verified through Firebug) Sadly, neither worked.

A sample url is

/bar/sessions/958d8a22-0/views/1493881172/export?format=application/pdf&no-attachment=true

which translates to a default Acrobat save as filename of

http___localhost_bar_sessions_958d8a22-0_views_1493881172_export_format=application_pdf&no-attachment=true.pdf

Update 3: Julian Reschke brings actual insight and rigor to this case. Please upvote his answer. This seems to be broken in FF (https://bugzilla.mozilla.org/show_bug.cgi?id=433613) and IE but work in Opera, Safari, and Chrome. http://greenbytes.de/tech/tc2231/#inlwithasciifilenamepdf

Part of the problem is that the relevant RFC 2183 doesn't really state what to do with a disposition type of "inline" and a filename.

Also, as far as I can tell, the only UA that actually uses the filename for type=inline is Firefox (see test case).

Finally, it's not obvious that the plugin API actually makes that information available (maybe someboy familiar with the API can elaborate).

That being said, I have sent a pointer to this question to an Adobe person; maybe the right people will have a look.

Related: see attempt to clarify Content-Disposition in HTTP in draft-reschke-rfc2183-in-http -- this is early work in progress, feedback appreciated.

Update: I have added a test case, which seems to indicate that the Acrobat reader plugin doesn't use the response headers (in Firefox), although the plugin API provides access to them.

Set the file name in ContentType as well. This should solve the problem.

context.Response.ContentType = "application/pdf; name=" + fileName;
// the usual stuff
context.Response.AddHeader("content-disposition", "inline; filename=" + fileName);

After you set content-disposition header, also add content-length header, then use binarywrite to stream the PDF.

context.Response.AddHeader("Content-Length", fileBytes.Length.ToString());
context.Response.BinaryWrite(fileBytes);

Like you, I tried and tried to get this to work. Finally I gave up on this idea, and just opted for a workaround.

I'm using ASP.NET MVC Framework, so I modified my routes for that controller/action to make sure that the served up PDF file is the last part of the location portion of the URI (before the query string), and pass everything else in the query string.

Eg:

Old URI:

http://server/app/report/showpdf?param1=foo&param2=bar&filename=myreport.pdf

New URI:

http://server/app/report/showpdf/myreport.pdf?param1=foo&param2=bar

The resulting header looks exactly like what you've described (content-type is application/pdf, disposition is inline, filename is uselessly part of the header). Acrobat shows it in the browser window (no save as dialog) and the filename that is auto-populated if a user clicks the Acrobat Save button is the report filename.

A few considerations:

In order for the filenames to look decent, they shouldn't have any escaped characters (ie, no spaces, etc)... which is a bit limiting. My filenames are auto-generated in this case, and before had spaces in them, which were showing up as '%20's in the resulting save dialog filename. I just replaced the spaces with underscores, and that worked out.

This is by no names the best solution, but it does work. It also means that you have to have the filename available to make it part of the original URI, which might mess with your program's workflow. If it's currently being generated or retrieved from a database during the server-side call that generates the PDF, you might need to move the code that generates the filename to javascript as part of a form submission or if it comes from a database make it a quick ajax call to get the filename when building the URL that results in the inlined PDF.

If you're taking the filename from a user input on a form, then that should be validated not to contain escaped characters, which will annoy users.

Hope that helps.

Try placing the file name at the end of the URL, before any other parameters. This worked for me. http://www.setasign.de/support/tips-and-tricks/filename-in-browser-plugin/

In ASP.NET 2.0 change the URL from

http://www. server.com/DocServe.aspx?DocId=XXXXXXX

to

http://www. server.com/DocServe.aspx/MySaveAsFileName?DocId=XXXXXXX

This works for Acrobat 8 and the default SaveAs filename is now MySaveAsFileName.pdf.

However, you have to restrict the allowed characters in MySaveAsFileName (no periods, etc.).

Comments
  • I just tried to add content-disposition inline; filename=foo.pdf and it seems to work in Chrome, at least.
  • He's already done that. Acrobat Reader ignores it, or so it seems.
  • Suggestion is to set ContentType = "application/pdf; name=foo.pdf" which he doesn't say he tried it.
  • I had high hopes, but this doesn't seem to affect Acrobat Reader 8.0 in IE or FF. Question updated.
  • Worked for me in FF 7.0 and Chrome 14. Failed in IE 9.
  • Awesome, I've been searching all over the internet for this feature and this is the place that I have found it. Thanks.
  • Sorry, but I believe this would be worse (with regards to user experience) than doing nothing. Renaming a file is not a huge deal, just an annoying one.
  • Fair enough. Gmail does this with images, and I quite like it personally. Good luck anyway :-)
  • That seems to rely on a bug in your web server? That should 404 according to spec - does Apache behave this way?
  • That's not completely insane, nor should it necessarily result in a 404. Additional paths following a CGI executable are valid, and should result in the CGI PATH_INFO variable being set. That said, I don't think it's the cleanest way of solving this problem.