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
Related
I am trying to redirect the user to simply another phtml file when they logout. I am using the function header like so:
header('Location: ../../Site/index.phtml');
exit;
In reality when that runs, the user is greeted if they want the file to be opened and they're not automatically re-directed. Like shown in the image. How can I get them to redirected please without the dialog (automatically). I am running a localhost.
Many thanks
Image of the output
The problem is likely due to the fact that .phtml is a very old PHP file extension (from PHP 2, circa 1997). We're now on PHP 7, and as such, most web servers don't even have logic built in to handle the .phtml extension.
Because your webserver (in this case localhost) doesn't know what to do with the file, it falls back and lets your browser handle it. Because your browser doesn't have an associated default file handler for the extension, it prompts you for an action (assuming a user would be more familiar with a file extension).
The easiest way to resolve this would be to simply switch to the .php extension, as I'm yet to encounter a server that is unable to handle the main PHP extension.
If you are still having issues opening the file, ensure that you specify the type of the file with header("Content-Type: text/html"), which is the default for PHP. This shouldn't be necessary, but will ensure that your browser correctly parses the file as a PHP file.
Hope this helps! :)
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.
When I attempt to navigate to the PHP script at http://localhost/project/admin, I expect to see the script results in my web browser.
Instead, I see a dialog box for downloading the file with the message below:
You have chosen to open <filename>, which is a: application/x-httpd-php from: http://localhost
What should Firefox do with this file? Open with... • Save... • etc.
Any idea what is going on?
PHP is not correctly installed on the server or Apache is not using mod_php
In the case of this happening in IIS. I would say that the mimetype is not setup correctly and that the server doesn't know how to handle the extension ".php"
It sounds like an incorrect Content-type header is being sent. This header sets the mime-type for the data the browser receives and, if the browser doesn't have a handler to render that specific mime-type, it will ask to open/save the file instead.
I would start by checking your PHP file for a header() statement and a mis-typed content-type.
On the current website I'm working on, I've got a directory of files for users to download which would be really nice to have some security method other than obscurity ;)
I was wondering if there's any way to supply login information via PHP to htaccess as though a user were entering it.
Alternately, if anyone knows a better way to secure user downloads using PHP, that's also acceptable. All of my googling turns up "just use htaccess" which isn't really helpful, as from the non-savvy user's point of view, they have to log in twice every time they use the website.
My best guess at doing it exclusively with PHP is to store files above the web root, then copy them to a web accessible folder temporarily, but this seems highly inefficient and I couldn't think up any way to remove them after the download has finished.
Note: I don't own the server this is running on and don't have ssh access to it.
If files are not too big (Gb) you can always use readfile for file's download. In this mode you can check user's auth before, and if it's ok output file contents to user, otherwise send him to login page.
With this method you can put your files in protected (with .htaccess) directory so you can be sure that nobody who isn't authenticated can access them.
I think I would either store them in a folder outside of the web root, or in a folder protected by .htaccess and then have a php script that checked if the user was logged in and allowed to download a file asked for. If he was, then just pass the file through to the user.
Example from linked page at php.net:
Example #1 Using fpassthru() with binary files
<?php
// open the file in a binary mode
$name = './img/ok.png';
$fp = fopen($name, 'rb');
// send the right headers
header("Content-Type: image/png");
header("Content-Length: " . filesize($name));
// dump the picture and stop the script
fpassthru($fp);
exit;
?>
Someone else made a comment about having to report the correct content-type, which is true. Often, in my own experience, I already know it, or can use the file extension pretty easily. Otherwise you can always try to have a look at finfo_file. On that page there are also some comments about what you could do especially for images as well.
you should use a php script to control the access.
create a dir outside the webroot or inside the webroot with a .htaccess where you location the download files.
outsite the webroot is better.
you have to make sure that no one can access those files if they are located inside.
then take from the pear class lib. the class http_download.
using this class has many advantages.
Ranges (partial downloads and resuming)
Basic caching capabilities
Basic throttling mechanism
On-the-fly gzip-compression
Delivery of on-the-fly generated archives through Archive_Tar and Archive_Zip
Sending of PgSQL LOBs without the need to read all data in prior to sending
you should not use readfile oder any forwarding filepointer because you have to set the headers yourself and the don't support http "range".
for the access restrictions you can use you session-manager, password, framework, forum etc.
pear - http_download http://pear.php.net/package/HTTP_Download
you need to copy the url, because SO encodes it to url-encoded string (which is correct), but PEAR-homepage doesn't like that.
Why reinvent the wheel? Take a look at File Thingy, which is pretty easy to install and customise. If nothing else, you can study the source to learn how to perform the authentication step.
You could use MySQL to store uploaded files, rather than storing them in a file, better and more secure, in my opinion. Just Google "MySQL upload php" for example.
You could create the htaccess file using a PHP script, from your users table, each time a user accesses that folder, very troublesome.
I think the first option is better.
Use X-SendFile! There's extensions for Apache, Lighty and Nginx so there's a good chance there's one for your webserver.
Once you have the extension installed, you can authenticate the user using your PHP script, and then add the header:
header('X-SendFile','/path/to/file');
When your PHP script is done, it will trigger the webserver to stream the file for you. This is especially efficient if you use PHP along with for example FastCGI, because it frees up the PHP process for other work.
Evert
I have asked this question today already but this time I want to know if I can achieve this via PHP since Javascript wasn't up to it.
I have a link to a file on another server. If i provide this link to my users the headers are pushed out to download that file from that server.
Is there a way for me to capture those headers and file and redirect the download to the user? I would like to do this so that I can change the filename of the download since it is
always 'file.zip'.
Is this possible with PHP?
Thank you for any help.
You can download the file to your server using curl and serve it correctly(with a Content-Disposition header). As long as you are using HTTP, there's no way to send just the header and let another server stream the content directly to the client.
You could do this, and you can do it in several ways.
1) (simple) copy the file to your server, and rename it. Point your download links to this copy.
2) (harder) Create a stub php file, called , read the file from the remote server within php, and stream the content to the script output. This will need you to set appropriate headers, etc. as well as setting up your webserver to parse through PHP.
Seriously, I'd go with option 1. (assumes you have a legal right to serve the content, etc.)
Maybe you can use a script similar to the following one:
<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.example.com/the_path/file.zip");
header('Content-Disposition: attachment; filename="alternate_filename.zip"');
exit();
?>