Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "J.O. Aho" Newsgroups: comp.lang.php Subject: Re: Downloading strangeness: downloaded file has no content Date: Sun, 2 Oct 2022 00:18:29 +0200 Lines: 65 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net BngcnI2SqHS93U24e0+jVQ33Vw4Y/FFnpDwUKgJZsZF1yGkM6i Cancel-Lock: sha1:4+3vHG+X5/754/WAY0xnt2BldHU= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Content-Language: en-US-large In-Reply-To: Xref: csiph.com comp.lang.php:19124 On 01/10/2022 21.44, Tim Streater wrote: > On 01 Oct 2022 at 17:47:31 BST, "J.O. Aho" wrote: > >> On 01/10/2022 16.50, Tim Streater wrote: >>> For those requesting that a file be downloaded from my website, having >>> selected a file (a .zip or a .dmg), the following is then executed: >>> >>> header('Content-Description: File Transfer'); >>> header('Content-Type: application/octet-stream'); >>> header('Content-Disposition: attachment; filename="' . basename ($file) . '"'); >>> header('Content-Transfer-Encoding: binary'); >>> header('Expires: 0'); >>> header('Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0'); >>> header('Pragma: public'); >>> header('Content-Length: ' . filesize ($file)); >>> >>> ob_clean (); >>> flush (); >>> readfile ($file); >>> >>> >>> For most of the files to be downloaded, this works just fine. But for one of >>> them, the downloaded file has zero content at the receiver's end: it is zero >>> bytes long. >> >> It could be a missing >> header('Content-Description: File Transfer'); > > That header is present. It's the first one. My bad, my brain just didn't want to see that line at all, as it had font-tag around it in the original post. >>> Any suggestions as to why this might be? >> >> If you are just doing what you paste here, I would suggest a direct link >> to the file instead. > > The above code is the end of the chain during which the user makes their > choice and has it validated. Before the above code there is some parameter > checking and a bit of logging. Jerry had some good points, I will extend one of his suggestions, the file permission and ownership, don't forget to look at the directories too, specially if you are running on Linux, so if one directory in the path do not have the right privileges set for the web server, then it will not be able to access anything in the subdirectories and files, even if they would have the correct privileges. Most likely in this case you need to look that either group rx on directories and r on files, some web-hosting sadly have it even worse and require other setting to have rx for directories and r for files. You will need to compare with a file that works to download from the web site with the one that do not work. I hope that ftp you mention is actually an sftp, otherwise anyone who can sniff the traffic will be able to get your password in plain text. -- //Aho