I have a web app which performs a character encoding conversion on .ssa files (SubStation Alpha - subtitle files basically). The MIME type of these files is text/plain. When the app performs the conversion it creates a link to download the new file. In Safari this works perfectly. However in Chrome when you click the download link it attempts to save the file as download.txt no matter what the actual filename is. In Firefox (beta) it tries to save it as something like kP3844h1.txt.part. How can I tell these browsers just to use the filename that is linked? In all cases the contents of the file is correct, it's just the name in the browser's "Save As..." dialog that gets screwed up.
Currently my .htaccess looks like:
AddType text/plain ssa
<Files *.ssa>
#ForceType application/octet-stream
Header set Content-Disposition attachment
</Files>
I've tried with both of the <Files> lines uncommented, and with either one commented on its own, but none of those options gives me the solution I'm looking for.
Also, the app is written in PHP, so if there's something I could be doing in the PHP code instead of messing with the .htaccess, I'm open to suggestions.
Use Content-Disposition attachment; filename="$actual_filename.txt" as header. Replace $actual_filename.txt by the actual name of the file. I have no idea if this is possible in the Apache configuration, but if you pipe the files through PHP, you might be able to set the header with the header function.
Related
I have Drupal website and my users can no longer download files. (docx, xlsx, etc). In firefox only, when the user clicks a link to download a file the page displays garbage code.
I read elsewhere the solution is to add the following, but it didn't work. Instead, the user is prompted with a dummy download for the application type each time the page reloads.
drupal_set_header('Content-type: application/octet-stream; charset=utf-8');
I have a simple module which has a page that spits out the links to the files. In this module I added the above to the hook_init() function.
I've never encountered this problem before, and I'm not sure why it started. Any help would of course be greatly appreciated. If I find a solution before someone replies with the answer I'll post it here for future reference.
Give this a roll for your MIME:
drupal_set_header('Content-type: application/force-download');
This happens because MIME types are not set correctly.
You can either force Drupal to set the content-type header to appropriate MIME type, or set it at the server side.
I'd recommend you to do it in the .htaccess file in your files folder (sites/default/files by default)
Just put the below code in the .htaccess file (or you can create a new .htaccess file if it's not there).
AddType application/octet-stream .doc .xls .pdf
Note that hook_init() gets fired at every normal page request. Never do this in this hook or you will end up facing many problems.
I'm working on a little project with a few friends, and have set up a pretty simple PHP upload script that only certain users can access. I am not worried about any type of attacks against the server, since this is for fun, but I do have a question.
I've made a subdomain (static.foo.bar) where the uploaded files are moved to. This subdomain had mod_php turned off, to prevent malicious upload and execution of php scripts. The script also checks for file extensions and mime content types, but I assume those can easily be bypassed/spoofed.
However, a user could easily upload an .html file and have it redirect somewhere else. Likewise, they could upload an image file instead and have it display an image in the browser, instead of being asked to download the image.
I assume this is the behavior of the browser, but I've also noticed that when uploading a file to sendspace (or any other service), even if the file is .html (and valid html) it will ask the user to download it instead of displaying it on the website.
I am running Apache on CentOS.
How do I accomplish this?
ForceType is probably what you're looking for.
# In your .htaccess file
<Location /uploads_directory>
ForceType application/octet-stream
</Location>
You want to set all files' mime type to application/octet-stream so the browser will download them instead of trying to show the content.
I am using ajax to post to a function that creates a PDF document through TCPDF.
Normally, I would just do a normal post to the function, and that would output the PDF, allowing the user to download teh pdf file. My understanding, however, is that this doesnt work with ajax, and that I instead need to save the pdf file on the server, and then return the url of the file to the ajax call.
Once I have the url, then I can do something like
window.location.assign(url/to/my.pdf);
Ok, so this all works fine, but its not great. Firstly, the pdf doesnt open in a new window (i.e. it currently opens in the same window), and secondly, I'd prefer to force the user to download the file rather than it opening in the browser.
Are there any other alternatives?
If you're using Apache for your web server, then you can add the following to an .htaccess file in the folder where your PDF files are generated to force a download.
<Files *.pdf>
ForceType application/pdf
Header set Content-Disposition attachment
</Files>
You could pass the generated PDF through PHP and set additional headers to force browser to download the document. See php force download extension.
I guess you can make these headers to be set by Apache automatically as well (e.g. for PDFs in particular folder).
I'm serving up Zip and PDF files on the fly via PHP using an output such as:
header('Content-Disposition: attachment; filename="'.$project->name .'.zip"');
echo($zipfile->zl_pack());
I can't find any reference to these downloads in my APACHE logs though. Is it not logged due to being dynamic?
Do I need to actually write the file to the webserver and then serve the result up to get it logged or am I missing something?
Cheers,
Niggles
Correct. httpd does not look at outgoing headers for logging. error_log() will send a message to httpd's error log, but there's no way to put something in the access log.
The request to the PHP program that generates that header should be logged. The filename mentioned in the content disposition header won't be.
I believe mod_perl would allow you to add custom logging, I don't know if mod_php provides a similar feature.
As a workaround you could use mod_rewrite to have the *.zip file logged and still served it through PHP without actually writing it to the filesystem, the client will have to send two requests though.
1) Change your current script so that it doesn't produce the file, but instead puts the parameters needed for the file creation in the session; instead of the current header and file content you would put header('Location: '.$project->name .'.zip');
2) This would cause the second request. Since the requested file doesn't exist yet, you would use mod_rewrite to change the request to a *.zip file to the same or some other PHP script that reads the parameters from the session and produces the file just like you're doing it now. If you use the same PHP script, you would additionally let mod_rewrite add some parameter like "?action=produceFile" to the request and then test for that parameter in the script.
This way you would have two nice entries in your Apache log without having to physically save the file (and probably delete it later).
FYI I found a really good work-around.
Part of the problem was that we wanted to force a "save as" dialogue as many of the users get confused as to where the file gets saved. So this is why I went the
Content-Disposition : attachment
method.
A better method which still invokes the dialogue is to add this to .htaccess
<Files *.zip>
ForceType application/octet-stream
Header set Content-Disposition attachment
</Files>
write the Zip to the fileserver and redirect the page to the zip.
Sure I have to cleanup every night, but it gets logged and it still forces them to choose where they download the file (on pretty much everything but Safari [ there's always one ]).
Cheers,
Niggles
I cant get a PHP file to send correct headers at my WAMP server. Wouldn't be a problem normally except that is phpMyAdmin that is freaking out and that the main css files are not working in Firefox.
Here's the row that in the file that merges the css files together, used to send the output as CSS.
header('Content-Type: text/css; charset=UTF-8');
I have also putted a .htaccess file in the phpmyadmin directory:
AddType text/css .css
Neither is working. What can I do to make sure that this file is interpreted as a CSS by firefox?
The Addtype directive is irrelevant - that tells the default handler to use the specified mimetype - in the case of PHP, you are not using the default handler.
The header comand should work set the mimetype header correctly - and the behaviour you describe does suggest that it is failing.
The most common reason for this fail is that the headers have already been flushed and body output has started before PHP gets to the header script. This can be due to all sorts of things (including BOM markers in UTF8 text files - which you can't usually see in your source code).
This also implies that your error handling / loging is broken - or you don't know where to lok for errors - take some time out to read the manual on how to configure error reporting.
C.