The HTTP content-disposition header does two things - it suggests to the browser how to open the file, and what to name the file. When you specify "attachment", you're actually overriding the browser's default behavior and telling it to save the file instead.
If you want it to open in the browser, change this value to "inline".
Also, you really only want a file name, and not a full path for "filename" setting. This does not refer to the original location on the server, and unless the browser has a severe security hole, the browser should not save the file at that location on the client, either. You should strip the path information off of the "filepath" String before setting it as the "filename" value.
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower
And, just in case you had hopes of literally opening the PDF in a web browser window, that doesn't work under Microsoft Windows. There's a patent on that technique and Microsoft lost a lawsuit to the tune of half a billion dollars, so they can only invoke an external program such as Adobe Reader to open and display the PDF.
Linux was exempted from that restriction. Although considering what the Reader plugin has been displaying for me lately, that's not as wonderful as it seems. The plugin can get pretty corrupt, requiring a browser restart to reset itself.
An IDE is no substitute for an Intelligent Developer.
The "inline" works well for me quite long time without any issues, but as "Tim" mentioned IE will get open the response by a third party software like adope reader but same will open in browser window itself. Clients had raised issues on this but closed all since it's the behaviour of IE.
No pain, No gain.
OCJP 1.6, Liferay Certified Developer 6.1