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).
Related
I am accessing this URL with my android device and the pdf download starts downloading automatically, without asking me to open the pdf vieth the pdf viewer.
This works in other websites.
I am the developer of the website. I set up the header to application/pdf. Any idea what can be the problem? Thank you.
Ok, I identified the problem and found the workaround.
It seems that the native android browser in not very intelligent. In fact, when a file is dowmloaded, the header of the file is not checked. The browser checks only the extension of the file in the url.
In my url, at the end we had /pdf, so no extension was found. By renaming the end of the url to xxx.pdf, the browser was able to recognize the file as a pdf.
On my Apache webserver i can server PDF files directly in the Browser with a simple Anchor link like:
Click to display PDF
This Works fine.
Now, i've got a lot of PDF's i want to Protect. So i moved them all outside the Web folder, and are serving them through a PHP download program - i called it download.php
To be sure that the pdf files are not downloaded as "download.php" i have to set the Content-Disposition Header to 'inline;filename="mysample.pdf"'. Inline because i want to open it in the Browser.
No Problem, all works fine. the files are downloading fine on Windows and Apple Browsers and are displayed IN the Browser, just like when its served directly from the Apache Server.
But my download.php doesn't work with Android Browsers... It's always just downloaded but not opened in the browser. You have to find the file in your messages and open it separately. When served directly from Apache it IS opened in the Browser.
It seems to be connected with Content-Disposition Header im setting in my download.php, because this is the only difference i see in the headers when download direct and indirect.
Anybody had the same problem?
Thanks
Per
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 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.
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