Hello: not so much php, more like HTML..?
am 31.08.2007 14:14:53 von Courtney
Ok. I need a little guidance here.
Environment.
===========
Apache2/PHP5/Mysql/debian etch.
Application
===========
I want data files to be stored somewhere apache can't get to them
directly, for security, but be available for download via a PHP script
(after various authentication stuff that seems to work so far) by
clicking on web page button, this to invoke:-
(a new page, that is actually a file download HTML thingie?)
Now it seems that if the opened URL is say a GET type form that takes
some form of file ID, and is a PHP program itself, all I need to do is a
mix of http_send_file() type stuff to push the data down a new browser
'window'
I.e conceptually if the button is a link to say :-
or whatever (never mind the syntax:
Thats what manuals are for) then essentially what my 'download_php'
wants to do is:-
- validate the user (REMOTE_USER) has rights to access the file, in case
of spoofing by manually typing the above command..
- send a load of header data (this is where I am unclear)
- send the file
- go back home.
Now in most cases these are files that do not require an application to
open them.
I want to ensure they get downloaded to disk,and only if the local
browser recognizes them, should they get opened by a local app.
Now the standard blurb shows this fragment as most of what I want, I think:
http_send_content_disposition("document.pdf", true);
http_send_content_type("application/pdf");
http_throttle(0.1, 2048);
http_send_file("/my_inaccessible_to_apache_path/report.pdf") ;
?>
But I need someone to confirm that this is the general approach that
will get me what I want, and enlighten me as to what mime types I
should use..and how this will interact with the browser, and its
understanding of MIME types.
TIA
Re: Hello: not so much php, more like HTML..?
am 02.09.2007 00:58:09 von Courtney
Rik Wasmus wrote:
>> its more efficient to have 5000 files all called 00001, 00002...05000
>> in one directory, or whether to split them up over several..and
>> whether to keep their names and extensions intact, or just be lazy,
>> knowing the data base knows what they were called.
>
> Hmm, depends on the file system, not really an expert there. Jerry would
> tell you to just serve them up straight from the database, and forget
> about the filesystem, I'm not so sure :).
I was wondering about that. It has a certain appeal..Would MySQL handle
60Mbyte Bitmap? I suppose so, when all is said and done..a LONGBLOB
would be enough..I suppose my fear is that the database might get
corrupted..at least with the files stashed on disk one could have some
chance of recovery.. Hmm.
Also performance..how long does it take to take the uploaded temporary
file and insert it into the database?
To move its directory and change its name is trivial..
You can do a little testing
> offcourse, see what works best.
mmm.
Will php allow you to read a 60Mbyte file into a string, and toss it
around like a 16 byte customer name?
If I could guarantee all files were small, I'd go that route.
But I just know someone is going to want to upload a whole movie one day
:-) :-)
Re: Hello: not so much php, more like HTML..?
am 04.09.2007 09:48:20 von Toby A Inkster
The Natural Philosopher wrote:
> I suspect the answer is that for n files, us the pth root of n as the
> number of subdirs, where p is the depth of the subdirs...but a lot
> depends on caching algorithms in the directories. AND the way the OS
> searches them.
Look at the way mail queue and news spools work. This is software that has
to maintain a large number of smallish files, which have to be created and
deleted a lot, but very rarely modified. That sounds like roughly what you
want to do.
For a piece of mail queued with ID A1B2C3D4 it would store it in:
/var/spool/postfix/deferred/A/A1B2C3D4
That is, it stores it in sub-directories based on the first character of
the queue ID. For larger numbers of files, you could go even further:
/var/spool/postfix/deferred/A/A1/A1B2C3D4
An important aspect of this is that queue IDs are eight-digit codes
assigned pseudo-randomly rather than sequentially, so you don't end up with
a directory called "/1/" brimming with files, and a directory called "/2/"
which is almost empty.
--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 75 days, 11:19.]
TrivialEncoder/0.2
http://tobyinkster.co.uk/blog/2007/08/19/trivial-encoder/
Re: Hello: not so much php, more like HTML..?
am 04.09.2007 13:19:32 von Courtney
Toby A Inkster wrote:
> The Natural Philosopher wrote:
>
>> I suspect the answer is that for n files, us the pth root of n as the
>> number of subdirs, where p is the depth of the subdirs...but a lot
>> depends on caching algorithms in the directories. AND the way the OS
>> searches them.
>
> Look at the way mail queue and news spools work. This is software that has
> to maintain a large number of smallish files, which have to be created and
> deleted a lot, but very rarely modified. That sounds like roughly what you
> want to do.
>
> For a piece of mail queued with ID A1B2C3D4 it would store it in:
>
> /var/spool/postfix/deferred/A/A1B2C3D4
>
> That is, it stores it in sub-directories based on the first character of
> the queue ID. For larger numbers of files, you could go even further:
>
> /var/spool/postfix/deferred/A/A1/A1B2C3D4
>
> An important aspect of this is that queue IDs are eight-digit codes
> assigned pseudo-randomly rather than sequentially, so you don't end up with
> a directory called "/1/" brimming with files, and a directory called "/2/"
> which is almost empty.
>
Well thanks for he reply..I discovered that
1/. my ext3 filesystem uses a hashed btree index
2/. so does my database
3/. ergo, it was easier to stuff them direct in the database, or would
have been but for a weird issue that kept me up all last night. see
other thread.. I thought it was something simple, but it looks like deep
weirdness at the core of PHP to me..but then everything does untill you
find the explanation.