Making clients use the proper filename on web file output

Actually, I do get a better "respect" for the filename, when using attachment.
That might very well be the solution to the matter -- I'm testing a little.

Of course, attachment makes the client prompt for "open or save file" - that's probably OK but a little irritating.

But why would the file name (filename=xxx.pdf) not be respected when not using attachment? Any explanation?

An alternative guess would be to use both
  Content-Disposition: filename="xxx.pdf"
  Content-Type: name="xxx.pdf"

The latter is non-standard (as I understand it) but may be interpreted by some clients.
I however haven't been able to test that yet. Any ideas on whether that may work better with some clients?

I'll return with info on whether attachment seems to completely solve the issue. It's the best guess right now.

The only alternative I know to 'attachment' is 'inline' which means the file is shown in the browser. I'm not sure how the filename is relevant in that case. The only situation I'm aware of where you want to force the filename to something else then the page url is exactly when the file is to be saved locally by the user. In short, I don't understand your situation but still I can only think of this solution ;-) The Content-Type that you suggest may be some sort of hack but seems ridiculous to me otherwise.

The reason for not using "attachment" but still wanting a real file name, is that the user shall get the document displayed as conventiently as possible, without the prompt "open or save"
At that point, when viewing the document, the user may select "save as" in the client program, i.e. IE or Acrobat Reader etc. Then the "filename" attribute should be proposed.
So the use of "filename" without "attachment" is quite handy.

With "attachment" it all seems to work quite OK, but the irritating "open or save" prompt is displayed, of course.
I would however have guessed that clients should respect the "filename" attribute even though "attachment" is not specified?
I cannot find any info in the specs on why not?

Also, I just recently discovered a critical problem with not respecting "filename" in this manner.
When a PDF is displayed in the IE browser, the user has the possiblity to "share via mail" (or similar term/text).
Then Outlook (or similar) is opened with the PDF attached to an empty message.
However, the filename is then given as "getpdf.exe" (not even using the PDF extension) and Outlook will then block the file as unsecure. Even though it is, of course, a PDF file.

With "attachment" the real filename is used instead.
So... attachment seems to be the solution.
However, then the prompt open/save pops up all the time.

So the real question is -- why is "filename" not respected by clients? Why on earth would the URL name be used when a filename is specified in the headers?

Sigh! :-)

It might just be that the 'syntax' of the header needs the disposition before the filename. Did you try:

Content-Disposition: inline; filename="myfile.pdf"

Select allOpen in new window

Also: I have seen problems with this before, it had to do with the quotes I think although these _are_ part of the standard. If you are not using this standard filename (myfile.pdf) but a real filename it might be worth exploring other options like urlencoding the filename instead of using quotes.

I have now tried with:
  Content-Disposition: filename="myfile.pdf"
  Content-Disposition: inline; filename="myfile.pdf"
  Content-Disposition: inline; filename=myfile.pdf

and with all three methods, the filename used by the client is based on "getpdf" instead of basing it on "myfile"
:-(

Increasing points to 500

Can you confirm this is just in Safari or all around?

I have found some ol ASP code that does a Server.URLEncode on the filename instead of using quotes for IE (old version probably).

Just to check this off, could you try:

Content-Disposition: inline; filename=myfile%2Epdf

Select allOpen in new window

Thanks for the suggestions.

However, using
  Content-Disposition: inline; filename=myfile%2Epdf

is equally faulted as the other three, not using the filename at all.
However, as soon as I switch to "attachment", it works ok -- but with that "open or save" prompt. Also, I think that depending on browser/Windows setting, I may run into cases when I get a "save" option only, and no automatic viewing at all.


I have not tested with Safari (I hope I didn't say that?) but mainly with IE9.

In IE9, when using the "save" icon in the browser window displaying the resulting PDF, the filename is proposed to be "getpdf.pdf"
When instead using the "mail as copy" icon in the browser window, the filename (attached into Outlook) is proposed to be "getpdf.exe.pdf"
Sigh!

Well, that URLEncoded option was probably only for IE7 or something.

I have not tested with Safari (I hope I didn't say that?)

Oops, no you didn't, that was just me...

There is of course one completely other way of doing this: save the file to disk and redirect to it. Was that already considered? You would probably have to schedule a cleanup script though (or fiddle with session events).

Using "attachment" is not the actual answer to the question, which is: how to make browsers respect the specified "filename" in a non-attachment (inline) Content-Disposition.

However, it solves the acute problem. It introduces a different (not good) behaviour, but still it is better than the alternative.