2010/3/30 Nathan Rixham <nrixham@xxxxxxxxx>:
> Jan G.B. wrote:
>> 2010/3/29 Nathan Rixham <nrixham@xxxxxxxxx>
>>
>>> Jan G.B. wrote:
>>>> 2010/3/29 Nathan Rixham <nrixham@xxxxxxxxx>
>>>>
>>>>> Jan G.B. wrote:
>>>>>> Top posting sucks, so I'll answer the post somewhere down there.
>>>>>> <SCNR>
>>>>>>
>>>>>> 2010/3/29 Devendra Jadhav <devendra.in@xxxxxxxxx>
>>>>>>
>>>>>>> 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@xxxxxxxxxx> 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.
>>>
>>
>> Yes. But the average persons posting here aren't server config gods, I
>> believe.
>> Also, you can not implement permissions on these files.
>> The discussion was about serving files from a place outside any docroot!
>> Guess there is a reason for that.
>>
>>
>>>> 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!
>>>
>>
>> Sure, you could configure your apache like that. Unless you have some
>> traffic on your site, because the time intensive thing for apache is to
>> spawn new processes. So it's just not a good idea to do that, Nor to serve
>> big files via file_get_contents.
>
> was only addressing and issue you pointed out.. anyways.. so you propose
> what exactly? don't server via apache, don't use file_get_contents
> instead do..?
>
> ps you do realise that virtually every "huge" file on the net is served
> via a web server w/o problems yeah?
>
>
I was recommending other file methods like fopen() combinations,
fpassthru() and at best readfile(). All of them do not buffer the
whole file in memory.
http://php.net/readfile
http://php.net/fpassthru
Regards
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
