+1  A: 

Not sure of the helpfulness of this resource (4 years old), but it may provide some hints:

http://www.datadynamics.com/forums/ShowPost.aspx?PostID=49196

{Had a excerpt here, but James Baker is right, it didn't apply; some parts of the thread do apply.}

micahwittman
by specifying attachment, that's what's causing it to open in a new window. not specifying that will open it in the browser anyway.
Darren Kopp
The quote is inapplicable to this question. There was some good commentary elsewhere, but nothing too helpful.
James Baker
A: 

You could always have two links. One that opens the document inside the browser, and another to download it (using an incorrect content type). This is what Gmail does.

Vincent McNabb
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.
James Baker
Fair enough. Gmail does this with images, and I quite like it personally. Good luck anyway :-)
Vincent McNabb
+4  A: 

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);
Vivek
He's already done that. Acrobat Reader ignores it, or so it seems.
Vincent McNabb
Suggestion is to set ContentType = "application/pdf; name=foo.pdf" which he doesn't say he tried it.
Vivek
I had high hopes, but this doesn't seem to affect Acrobat Reader 8.0 in IE or FF. Question updated.
James Baker
A: 

Instead of attachment you can try inline:

Response.AddHeader("content-disposition", "inline;filename=MyFile.pdf");

I used inline in a previous web application that generated Crystal Reports output into PDF and sent that in browser to the user.

ManiacZX
A: 

Thats correct, i also test lot of things but cannot make the save as from browser as file name. even EXT=/aabbcc.pdf in the URL dosnt work

+3  A: 

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.

Troy Howard
A: 

Hi. I was redirected here because i have the same problem. I also tried Troy Howard's workaround but it is doesn't seem to work.

The approach I did on this one is to NO LONGER use response object to write the file on the fly. Since the PDF is already existing on the server, what i did was to redirect my page pointing to that PDF file. Works great.

http://forums.asp.net/t/143631.aspx

I hope my vague explanation gave you an idea.

  • Mark
+2  A: 

Oh how I wish this problem were solved and I didn't just waste 5 hours of my life on it. My experience confirms what has already been stated here, which is that it just isn't possible to do (I'm testing on FF3 with Acrobat 9.1). With respect to default "save" filename, Acrobat appears to take anything after a question mark in the URL and chuck it, convert all slashes to underscores, and if the final item in the URL before the question mark has an extension other than "pdf", it changes it to "pdf".

Please oh please tell me Acrobat will fix this at some point.

+4  A: 

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.

Julian Reschke
A: 

Try this, if your executable is "get.cgi"

http://server,org/get.cgi/filename.pdf?file=filename.pdf

Yes, it's completely insane. There is no file called "filename.pdf" on the server, there is directory at all under the executable get.cgi.

But it seems to work. The server ignores the filename.pdf and the pdf reader ignores the "get.cgi"

Dan

That seems to rely on a bug in your web server? That should 404 according to spec - does Apache behave this way?
James Baker
+1  A: 

I believe this has already been mentioned in one flavor or another but I'll try and state it in my own words.

Rather than this:

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

I use this:

/bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf?GeneratePDF=1

Rather than having "export" process the request, when a request comes in, I look in the URL for GeneratePDF=1. If found, I run whatever code was running in "export" rather than allowing my system to attempt to search and serve a PDF in the location "/bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf" If GeneratePDF is not found in the URL, I simply transmit the file requested. (note that I can't simply redirect to the file requested - or else I'd end up in an endless loop)

+1  A: 

If you use asp.net, you can control pdf filename through page (url) file name. As other users wrote, Acrobat is a bit s... when it choose the pdf file name when you press "save" button: it takes the page name, removes the extension and add ".pdf". So /foo/bar/GetMyPdf.aspx gives GetMyPdf.pdf.

The only solution I found is to manage "dynamic" page names through an asp.net handler:

  • create a class that implements IHttpHandler
  • map an handler in web.config bounded to the class

Mapping1: all pages have a common radix (MyDocument_):

<httpHandlers>  
<add verb="*" path="MyDocument_*.ashx" type="ITextMiscWeb.MyDocumentHandler"/>

Mapping2: completely free file name (need a folder in path):

<add verb="*" path="/CustomName/*.ashx" type="ITextMiscWeb.MyDocumentHandler"/>

Some tips here (the pdf is dynamically created using iTextSharp):
http://fhtino.blogspot.com/2006/11/how-to-show-or-download-pdf-file-from.html

Fabrizio
A: 

The way I solved this (with php ) is as follows:

Suppose your url is SomeScript.php?id=ID&data=DATA and the file you want to use is TEST.pdf

Change the url to SomeScript.php/id/ID/data/DATA/EXT/TEST.pdf

It's important that the last parameter is the file name you want adobe to use (the 'EXT' can be about anything). Make sure there are no special chars in the above string, BTW.

Now you at the top of SomeScript.php add

$_REQUEST = MakeFriendlyURI( $_SERVER['PHP\_SELF'], $_SERVER['SCRIPT_FILENAME']);

Then add this function to SomeScript.php (or your function library):

function MakeFriendlyURI($URI, $ScriptName) {

/* Need to remove everything up to the script name */
$MyName = '/^.*'.preg_quote(basename($ScriptName)."/", '/').'/';
$Str = preg_replace($MyName,'',$URI);
$RequestArray = array();

/* Breaks down like this
   0      1     2     3     4     5
 PARAM1/VAL1/PARAM2/VAL2/PARAM3/VAL3
*/

$tmp = explode('/',$Str); 
/* Ok so build an associative array with Key->value
   This way it can be returned back to $_REQUEST or $_GET
 */
for ($i=0;$i < count($tmp); $i = $i+2){
 $RequestArray[$tmp[$i]] = $tmp[$i+1];
}
return $RequestArray;  
}//EO MakeFriendlyURI

Now $_REQUEST (or $_GET if you prefer) is accessed like normal $_REQUEST['id'], $_REQUEST['data'], etc

And Adobe will use your desired file name as the default save as or email info when you send it inline.

Rick

Rick Cooper
A: 

For anyone still looking at this, I used the solution found here and it worked wonderfully. Thanks Fabrizio!

Brian