Joe Schaefer wrote:

Kemin Zhou <[EMAIL PROTECTED]> writes:



To the Developers,

I saw this in the documentation for Apache::Request

for file upload

      tempname [XXX- Does this mesh with brigade API?]

Provides the name of the spool file. This method is reserved for
debugging purposes, and is possibly subject to change in a future
version of Apache::Request.

From a user's point view, this methods has to be available to the
users and not removed in the future.



[...]

Despite my past grumblings to the contrary, I've added support for tempname
to httpd-apreq-2's current-cvs. I don't know what sort of security
implications you are concerned about, but perhaps the best thing to do
is simply not use tempname, instead using link() - and then delete the linked file yourself once the external app is done with it.




Joe,
Thanks for the help. The tempname is not available in mp2. There is another method that I found


slurp() it gave the content of the file and this method work fine for me. The ->fh method is gone too. While I was reading the
documents for link() I did not understand how to use it. I will go back and read the doc again.


I don't know how this is implemented. I used to write my own file upload method. Some of my web applications
still use these methods. It is very simple. Nower days all the servers have huge amount of memory. The
content can be read into a variable. Somewhere in the configure file , or in the function call itself,
there should be a way to set the limit
for the size of the upload; to prevent an attacher to send you a GIG byte file. Then the programer can
write the content to a file.


If the module puts the content of the upload into a file (temp hopefully),
and the programer is only interested in the name of the file, he/she does not have to read from the file
handle and put it into another file (duplicate effort). If the programer is only interested interested in
the content of the file, writting the file to disk may reduce the performance.


Put more thoughts into uploads could benefit the future.

Kemin





**********************************************************************
Proprietary or confidential information belonging to Ferring Holding SA or to one of 
its affiliated companies may be contained in the message. If you are not the addressee 
indicated in this message (or responsible for the delivery of the message to such 
person), please do not copy or deliver this message to anyone. In such case, please 
destroy this message and notify the sender by reply e-mail. Please advise the sender 
immediately if you or your employer do not consent to e-mail for messages of this 
kind. Opinions, conclusions and other information in this message represent the 
opinion of the sender and do not necessarily represent or reflect the views and 
opinions of Ferring.
**********************************************************************


-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Reply via email to