deleting a file after user download it

Question 1

I am using this for sending file to user

header('Content-type:  application/zip');
header('Content-Length: ' . filesize($file));
header('Content-Disposition: attachment; filename="file.zip"');
readfile($file);

I want to delete this file after user downloads it, how can i do this?

EDIT: My scenario is like that, when user hits download button, my script will create a temporary zip file and user download it then that temp zip file will be deleted.

EDIT2: OK best way seems running a cron job that will be cleaning temp files once an hour.

EDIT3: I tested my script with unlink, it works unless user cancel the download. If user cancel the download, zip file stays on the server. So that is enough for now. :)

EDIT4: WOW! connection_aborted() made the trick !

ignore_user_abort(true);
if (connection_aborted()) {
    unlink($f);
}

This one will delete the file even if user cancel the download.

Question 2

unlink($filename);

This will delete the file.

It needs to be combined with ignore_user_abort()^Docs so that the unlink is still executed even the user canceled the download.

ignore_user_abort(true);

...

unlink($f);

Question 3

Here's what worked best for me when trying to script this (in case anyone else comes across this like I did):

$ pecl -d php_suffix=5.6 install <package>
$ pecl uninstall -r <package>

$ pecl -d php_suffix=7.0 install <package>
$ pecl uninstall -r <package>

$ pecl -d php_suffix=7.1 install <package>
$ pecl uninstall -r <package>

The -d php_suffix=<version> piece allows you to set config values at run time vs pre-setting them with pecl config-set. The uninstall -r bit does not actually uninstall it (from the docs):

vagrant@homestead:~$ pecl help uninstall
pecl uninstall [options] [channel/]<package> ...
Uninstalls one or more PEAR packages.  More than one package may be
specified at once.  Prefix with channel name to uninstall from a
channel not in your default channel (pecl.php.net)

Options:
  ...
  -r, --register-only
        do not remove files, only register the packages as not installed
  ...

The uninstall line is necessary otherwise installing it will remove any previously installed version, even if it was for a different PHP version (ex: Installing an extension for PHP 7.0 would remove the 5.6 version if the package was still registered as installed).

Question 4

Well, you'll have to first create the zipfile, using the ZipArchive class.

Then, send :

The right headers, indicating to the browser it should download something as a zip -- see header() -- there is an example on that manual's page that should help
The content of the zip file, using readfile()

And, finally, delete the zip file from your server, using unlink().

Note : as a security precaution, it might be wise to have a PHP script running automatically (by crontab, typically), that would delete the old zip files in your temporary directory.

This just in case your normal PHP script is, sometimes, interrupted, and doesn't delete the temporary file.

Question 5

Never used any of those, but they look interesting..

Take a look at Gearman as well.. more overhead in systems like these but you get other cool stuff :) Guess it depends on your needs ..

Question 6

You didn't say, but let's assume this is an HTTP connection.

In short, they are doing it to save bandwidth. 3G isn't Free!

If you are directly requesting resources (GET), then you are at the mercy of all intermediaries that process the HTTP response (i.e. proxies, gateways), and you can be sure they can see the MIME type in the headers, and behave accordingly.

You can try using the HTTP Accept header in your request, and use the q parameter to "hint" that you want maximum fidelity.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Accept: image/png;q=1

The q ranges from 0 to 1. You may be able to get away with a lower value (than 1). Please read the linked section for more details.

You can also inspect the incoming Content-Type header; it may reveal if there's a "declared" change in quality or even MIME type. It may be telling you what it did!

It would be excellent if the "standard" does its job for you!

If that doesn't work, and you are in control of the server end already, use an alternate text-based encoding for it, like Base64, that intermediaries cannot "compress" for you. SOAP has been doing that since ever!

If you really really need to bypass image compression, and Accept doesn't work, you must proxy those kinds of requests yourself, and re-encode them with a non-image MIME type in the response.

If you are going the self-proxy route, you could probably get away with calling your images application/octect-stream which is the MIME type for "uninterpreted bytes". This would allow for more-or-less pass-through of the data, and hopefully keep intermediaries "helping hands" off your stuff!

deleting a file after user download it

Answers

php