views:

1133

answers:

5

How do I make my Apache 2 server force a browser to open a file transfer dialogue if the URL points to a file with a .pln or .psa extension?

I have a simple LAMP server with CentOS 5, Apache 2, MYSQL 5, PHP 5, recently built CentOS 5.2 i386 installation CDs. My web application generates files to be downloaded and imported into a custom application. The file extensions are .psa and .pln. How do I make my server force the browser to open a file transfer dialogue? If I point my browser to a .psa or .pln file on the Apache 2 server, the file's content is displayed in a pop-up window as simple text. I want a file transfer dialogue.

The web-app I am working on is deployed on another web-server and handles the .pln and .psa files as desired. I cannot compare server configuration files because I do not have administrator access to the working server.

How do I change my server's behavior? Does this require code changes to my web-app code (such as sending explicit headers)? If so, why does it work against the other server? Can code changes be avoided by configuring the server's default behavior?

Any help would be appreciated.

+3  A: 

You should be able to use the FilesMatch directive to add the necessary header.

<FilesMatch "\.(?i:pin)$">
  Header set Content-Disposition attachment
</FilesMatch>
palehorse
I added the lines above to my /etc/httpd/conf/httpd.conf file and restarted the httpd service (I also tried it with pln instead of pin). The .psa and .pln files are still being displayed as text in my browser.
Sorry, misread the extension. The RegEx syntax would be "\.(?i:pln)|(?i:psa)$"Did you try putting it in your .htaccess file. In addition, you can add the line:Header ContentType applicaiton/octentjust before the other Header line.
palehorse
Thanks. Adding the following to my /etc/httpd/conf/httpd.conf file fixed the problem.<FilesMatch "\.(pln|psa)$"> ForceType application/unknown Header set Content-Disposition attachment</FilesMatch>I had to clear my browser's (IE7) temporary internet files for changes to take effect.
The "ForceType application/unknown" entry causes the file transfer dialogue box type to be "Unknown File Type". Without it, the type displayed is "HTML Document" which is incorrect.
That makes sense. You could probably also add entries to the servers MIME type configuration, but that may be overkill.
palehorse
A: 

Forcing a browser to do something is always a tricky proposition, since the browser can ignore you and do what the hell it likes :)

That said, most browsers will prompt the user with a "save as" dialog box if the "Content-type" header is set to "application/octet-stream". Either write a simple wrapper cgi that serves up the requested file with the correct header, or fiddle with Apache2's mime-types (look in the config directory.)

Hope this helps, happy hacking (and happy Christmas, New Year or whatever you may celebrate)

Misha

A: 

Ahh, didn't know about that header palehorse, that's probably a better way, since it allows you to preserve the original MIME type, will have to remember that one.

You can set the Content Type using that method as well if you want to force application/octet. Just add Header ContentType applicaiton/octet. That my make it a little more reliable.Doing it in the conf or .htaccess is nice, avoiding the download file script.
palehorse
A: 

I tried several configuration changes which had no apparent effect.

  1. I added the following line to my /etc/httpd/conf/httpd.conf file:

AddType application/octet-stream .pln .psa

I restarted the Apache server and it had no effect.

  1. I added the following lines to my /etc/httpd/conf/httpd.conf file: ForceType application/octet-stream Header set Content-Disposition attachment ForceType application/octet-stream Header set Content-Disposition attachment I restarted the Apache server and it had no effect.
Did you try the FilesMatch syntax?
palehorse
Yes. See my comments above. The FilesMatch directive solved my problem.
A: 

If you have Firefox (and if not, why not?) install Chris Pedericks Developer Toolbar, and check that the headers are actually being set correctly. If so, it may be the fault of the browser. As I said, you can't be certain that any given browser will "correctly" interpret the response headers. What browser are we talking about here anyway?

If the headers aren't being set correctly, you may need to re-check your httpd.conf file. Possibly the directives you added aren't in the correct section? (e.g. under the wrong <Location > directive)