Re: how to provide download of files mow in documentroot

Jan G.B. wrote: > 2010/3/29 Nathan Rixham <nrixham@gmail.com> > >> Jan G.B. wrote: >>> Top posting sucks, so I'll answer the post somewhere down there. >>> <SCNR> >>> >>> 2010/3/29 Devendra Jadhav <devendra.in@gmail.com> >>> >>>> Then you can do file_get_contents within PHP. or any file handling >>>> mechanism. >>>>>> On Mon, Mar 29, 2010 at 1:00 AM, ebhakt <im@ebhakt.com> wrote: >>>>>>> Hi >>>>>>> i am writing a web application in php >>>>>>> this webapp primarily focuses on file uploads and downloads >>>>>>> the uploaded files will be saved in a folder which is not in document >>>>>>> root >>>>>>> and my query is how will i be able to provide download to such files >>>> not >>>>>>> located in document root via php >>>>>>> >>> Try something like that >>> <?php >>> $content = file_get_contents($filename); >>> $etag = md5($content); >>> header('Last-Modified: '.gmdate('D, d M Y H:i:s', >>> filemtime($filename)).' GMT'); >>> header('ETag: '.$etag); >>> header('Accept-Ranges: bytes'); >>> header('Content-Length: '.strlen($content)); >>> header('Cache-Control: '.$cache_value); // you decide >>> header('Content-type: '.$should_be_set); >>> echo $content; >>> exit; >>> ?> >>> >>> Depending on the $filesize, you should use something else than >>> file_get_contents() (for example fopen/fread). file_get_contents on a >> huge >>> file will exhaust your webservers RAM. >> Yup, so you can map the <Directory /path/to> in web server config; then >> "allow from" only from localhost + yourdomain. This means you can then >> request it like an url and do a head request to get the etag etc then >> return a 304 not modified if you received a matching etag Last-Modified >> etc; (thus meaning you only file_get_contents when really really needed). >> >> I'd advise against saying you Accept-Ranges bytes if you don't accept >> byte ranges (ie you aren't going to send little bits of the file). >> >> If you need the downloads to be secure only; then you could easily >> negate php all together and simply expose the directory via a location >> so that it is web accessible and set it up to ask for "auth" using >> htpasswd; a custom script, ldap or whatever. >> >> And if you don't need security then why have php involved at all? simply >> symlink to the directory or expose it via http and be done with the >> problem in a minute or two. >> >> Regards! >> > > In my opinion, serving user-content on a productive server is wicked sick. > You don't want your visitors to upload malicous files that may trigger some > modules as mod_php in apache. So it makes sense to store user-uploads > outside of a docroot and with no symlink or whatsover. even the simplest of server configurations will ensure safety. just use .htaccess to SetHandler default-handler which treats everything as static content and serves it right up. > One more thing added: your RAM will be exhausted even if you open that 600mb > file just once. > Apaches memory handling is a bit weird: if *one* apache process is using > 200mb RAM on *one* impression because your application uses that much, then > that process will not release the memory while it's serving another 1000 > requests for clear.gif which is maybe 850b in size. again everything depends on how you have your server configured; you can easily tell apache to kill each child after one run or a whole host of other configs; but ultimately if you can avoid opening up that file in php then do; serving statically as above is the cleanest quickest way to do it (other than using s3 or similar). regards!