[27812] in Perl-Users-Digest
Perl-Users Digest, Issue: 9176 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 19 18:05:44 2006
Date: Wed, 19 Apr 2006 15:05:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 19 Apr 2006 Volume: 10 Number: 9176
Today's topics:
[RDBO] ANNOUNCE: Rose::DB::Object 0.72 released <siracusa@mindspring.com>
clpmisc posting guidelines question <blabla@yourguess.com>
Re: clpmisc posting guidelines question <jgibson@mail.arc.nasa.gov>
Re: How to find uploaded data size from content-length xhoster@gmail.com
Re: How to find uploaded data size from content-length xhoster@gmail.com
Re: How to find uploaded data size from content-length <john@castleamber.com>
Re: How to find uploaded data size from content-length <no@thanks.com>
Re: How to find uploaded data size from content-length <no@thanks.com>
Re: How to find uploaded data size from content-length <no@thanks.com>
Re: How to find uploaded data size from content-length <no@thanks.com>
Re: How to find uploaded data size from content-length <john@castleamber.com>
Re: How to find uploaded data size from content-length <××DBraughler××@××bwcc·com>
Re: How to find uploaded data size from content-length xhoster@gmail.com
Re: How to find uploaded data size from content-length xhoster@gmail.com
Re: How to find uploaded data size from content-length <sherm@dot-app.org>
Re: How to find uploaded data size from content-length <sherm@dot-app.org>
Re: How to find uploaded data size from content-length xhoster@gmail.com
Re: Term::ReadKey on Win? 5.005 vs 5.8.8? <nospam-abuse@ilyaz.org>
Re: Term::ReadKey on Win? 5.005 vs 5.8.8? <mothra@nowhereatall.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 19 Apr 2006 13:03:42 GMT
From: John Siracusa <siracusa@mindspring.com>
Subject: [RDBO] ANNOUNCE: Rose::DB::Object 0.72 released
Message-Id: <IxzM55.1GoE@zorch.sf-bay.org>
This is another release with important bug fixes. The ref-count stuff in
particular should make a big difference in persistent environments like
mod_perl.
Files sent to CPAN and on SF.net now:
http://sourceforge.net/project/showfiles.php?group_id=147570
Changes below.
-John
0.72 (04.19.2006) - John Siracusa <siracusa@mindspring.com>
* Many reference-count bugs fixed, including several that could cause
database handles to leak.
* Fixed a bug that could cause "empty" sub-objects to be created when
processing certain with_objects parameters.
* Improved the accessor/mutator methods for these column types: set,
array, and boolean.
* Changed the BigInt and BigSerial column classes to use normal Perl
scalars instead of Math::BigInt objects when perl has been compiled
to use native 64-bit integers. (Suggested by Jesse Brown)
* Added the inject_results Manager parameter to bypass the standard
object creation mechanism in cases where it's the dominant factor
in overall performance.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
------------------------------
Date: Wed, 19 Apr 2006 20:30:22 +0200
From: Nico Coetzee <blabla@yourguess.com>
Subject: clpmisc posting guidelines question
Message-Id: <e25vjr$6kv$1@ctb-nnrp2.saix.net>
Recently ("autoincrement hex numbers" thread) an argument was started
between what to use first as a solution to a problem: a Perl built-in or
a CPAN module.
Yet, in FAQ 4.45 (as an example, because it was posted recently) a
simple solution is provided by using the CPAN module first, then
explaining how to do it in "pure" Perl.
Now I am curious... What do we actually use first when giving advice? Do
we need to explain "why" we actually prefer a certain piece of advice
above another? Is it necessary to "defend" an option, or should we not
rather just make another suggestion (not putting it forward as "better")?
Sorry in advance if this was covered before - I have read
http://www.catb.org/~esr/faqs/smart-questions.html and
http://www.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.text but I
must admit I did not really find the answers to the above questions, but
if I'm wrong please correct me.
Thanks
Nico
------------------------------
Date: Wed, 19 Apr 2006 13:32:28 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: clpmisc posting guidelines question
Message-Id: <190420061332289226%jgibson@mail.arc.nasa.gov>
In article <e25vjr$6kv$1@ctb-nnrp2.saix.net>, Nico Coetzee
<blabla@yourguess.com> wrote:
> Recently ("autoincrement hex numbers" thread) an argument was started
> between what to use first as a solution to a problem: a Perl built-in or
> a CPAN module.
>
> Yet, in FAQ 4.45 (as an example, because it was posted recently) a
> simple solution is provided by using the CPAN module first, then
> explaining how to do it in "pure" Perl.
>
> Now I am curious... What do we actually use first when giving advice? Do
> we need to explain "why" we actually prefer a certain piece of advice
> above another? Is it necessary to "defend" an option, or should we not
> rather just make another suggestion (not putting it forward as "better")?
There is a certain amount of overhead in using a module, which can vary
quite a bit. Some modules are part of the standard Perl installation,
so the overhead is minimal. Other modules must be downloaded and
installed, requiring root access or installation for each user and
adding lib statements to your code or defining an environment variable
such as PERL5LIB. Also, non-standard modules will need to be installed
on every system where they are used, not always an easy task.
There is another risk with modules, and that is quality. Anybody can
upload a module to CPAN. Some modules are well-designed and written and
thoroughly tested. However, that is not always the case. I have no
problem recommending any of the core set of modules. Nor do I hesitate
to recommend those with which I have used extensively.
Therefore, a smart and cautious person will always consider using basic
Perl functionality in preference to a module, because it is simpler,
portable, and more reliable. In this case, the functionality was to
convert a number to a hex representation, something that can be done in
one line, so no module is needed or, usually, desired.
There are exceptions, of course. Some modules have been written to
extend the Perl language. For example, File::Find is very popular
module because it simplifies a common task: traversing a directory tree
and processing all files within it. You can do the same thing in basic
Perl using opendir, readdir, and closedir, but not as simply. That is
why File::Find is now a standard module.
>
> Sorry in advance if this was covered before - I have read
> http://www.catb.org/~esr/faqs/smart-questions.html and
> http://www.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.text but I
> must admit I did not really find the answers to the above questions, but
> if I'm wrong please correct me.
Those references are designed to help people ask questions on Usenet.
They don't address how to answer questions. That is also an art, but of
a different nature.
When asked how to solve a problem, people will answer with many
different possible solutions. It is up to you to pick the one best
suited to your particular problem. It is best if people would carefully
list the tradeoffs for each solution, but not everybody has the time.
The same questions keep getting asked, so nobody wants to give a full
explanation or justification in each case. If we did, then fewer people
would get their questions answered.
Thanks for posing your questions and keeping the discussion civil.
------------------------------
Date: 19 Apr 2006 18:21:17 GMT
From: xhoster@gmail.com
Subject: Re: How to find uploaded data size from content-length
Message-Id: <20060419143435.067$oG@newsreader.com>
John Bokma <john@castleamber.com> wrote:
> Asterbing <no@thanks.com> wrote:
>
> > In article <Xns97AA6D15AEC7Fcastleamber@130.133.1.4>,
> > john@castleamber.com says...
> >> Why not -s filename assuming you store it in a file system?
> >
> > Because I would like to avoid too big files
>
> Ok, so your question actually is: how do I avoid the uploading of big
> files:
>
> $CGI::POST_MAX
>
> If set to a non-negative integer, this variable puts a ceiling on the
> size of POSTings, in bytes. If CGI.pm detects a POST that is greater than
> the ceiling, it will immediately exit with an error message.
That should probaby be changed. It does not immediately exit with
an error message. It first reads (and discards) the entire contents
of the POST, which apparently the OP doesn't want to happen althought it
is kind of hard to figure out exactly what he wants. Also, it doesn't
exit at all. It causes param to return an empty param list, and it causes
cgi_error to return an error message--no exiting involved.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 19 Apr 2006 18:31:12 GMT
From: xhoster@gmail.com
Subject: Re: How to find uploaded data size from content-length
Message-Id: <20060419144430.442$mT@newsreader.com>
Asterbing <no@thanks.com> wrote:
> In article <20060419114637.129$Vc@newsreader.com>, xhoster@gmail.com
> says...
> >
> > No.
> >
>
> Why ?
Why isn't the moon made out of green cheese?
You pretty much covered why in the post. You can't figure out how the
sizes of the different parts of the post (which sum up to CONTENT_LENGTH)
are distributed until you read all but one of them. Since you can't
gaurantee that the part which contains the file upload is the last part,
you can't figure out how big that part is until you have read it.
I have no idea why you think you need to do this.....
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 19 Apr 2006 19:17:52 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <Xns97AA916DBEDB4castleamber@130.133.1.4>
xhoster@gmail.com wrote:
> John Bokma <john@castleamber.com> wrote:
>> Asterbing <no@thanks.com> wrote:
>>
>> > In article <Xns97AA6D15AEC7Fcastleamber@130.133.1.4>,
>> > john@castleamber.com says...
>> >> Why not -s filename assuming you store it in a file system?
>> >
>> > Because I would like to avoid too big files
>>
>> Ok, so your question actually is: how do I avoid the uploading of big
>> files:
>>
>> $CGI::POST_MAX
>>
>> If set to a non-negative integer, this variable puts a ceiling on
>> the
>> size of POSTings, in bytes. If CGI.pm detects a POST that is greater
>> than the ceiling, it will immediately exit with an error message.
>
> That should probaby be changed. It does not immediately exit with
> an error message. It first reads (and discards) the entire contents
> of the POST, which apparently the OP doesn't want to happen althought
> it is kind of hard to figure out exactly what he wants. Also, it
> doesn't exit at all. It causes param to return an empty param list,
> and it causes cgi_error to return an error message--no exiting
> involved.
You mean it reads until it detects that the max size has been reached?
Yes, that's what I expect, since one can keep streaming bytes, and only
when the max has been reached the script knows it was too much.
The second part: if the documentation is wrong, it must be fixed. Did you
submit this?
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: Wed, 19 Apr 2006 21:17:09 +0200
From: Asterbing <no@thanks.com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <MPG.1eb0ab1c12d01ed8989803@news.tiscali.fr>
In article <20060419144430.442$mT@newsreader.com>, xhoster@gmail.com
says...
> I have no idea why you think you need to do this.....
>
Because when CONTENT_LENGTH has been informed by server itself after
receiving of entire POST, I can effectively read STDIN, extract uploaded
data and do the substraction.
But, when CONTENT_LENGTH comes from original request, how to proceed ?
Say, I wish to avoid any upload (I mean write on server, since data may
already be in STDIN) above 1MB, how to proceed ?
------------------------------
Date: Wed, 19 Apr 2006 21:20:59 +0200
From: Asterbing <no@thanks.com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <MPG.1eb0ac08e8d3b748989804@news.tiscali.fr>
In article <Xns97AA8023D74CDcastleamber@130.133.1.4>,
john@castleamber.com says...
> $CGI::POST_MAX
>
> If set to a non-negative integer, this variable puts a ceiling on the
> size of POSTings, in bytes. If CGI.pm detects a POST that is greater than
> the ceiling, it will immediately exit with an error message. This value
> will affect both ordinary POSTs and multipart POSTs, meaning that it
> limits the maximum size of file uploads as well. You should set this to a
> reasonably high value, such as 1 megabyte.
>
Without CGI.pm !
However, reading what you posted from CGI.pm help, it seems that CGI.pm
doesn't really limit the file size precisely but rather the entire
POSTed data. So, how if I want to be free to choose the file limit not
as 1MB but as 5KB ?
------------------------------
Date: Wed, 19 Apr 2006 21:24:09 +0200
From: Asterbing <no@thanks.com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <MPG.1eb0acb59e072233989805@news.tiscali.fr>
In article <20060419143435.067$oG@newsreader.com>, xhoster@gmail.com
says...
> John Bokma <john@castleamber.com> wrote:
> > Asterbing <no@thanks.com> wrote:
> >
> > > In article <Xns97AA6D15AEC7Fcastleamber@130.133.1.4>,
> > > john@castleamber.com says...
> > >> Why not -s filename assuming you store it in a file system?
> > >
> > > Because I would like to avoid too big files
> >
> > Ok, so your question actually is: how do I avoid the uploading of big
> > files:
> >
> > $CGI::POST_MAX
> >
> > If set to a non-negative integer, this variable puts a ceiling on the
> > size of POSTings, in bytes. If CGI.pm detects a POST that is greater than
> > the ceiling, it will immediately exit with an error message.
>
> That should probaby be changed. It does not immediately exit with
> an error message. It first reads (and discards) the entire contents
> of the POST, which apparently the OP doesn't want to happen althought it
> is kind of hard to figure out exactly what he wants. Also, it doesn't
> exit at all. It causes param to return an empty param list, and it causes
> cgi_error to return an error message--no exiting involved.
>
> Xho
>
>
OK, so it doesn't specifically limit the size of uploadable file (but
size of entire POST) and it doesn't avoid sending of entire POST data
from web browser to server's STDIN ?
------------------------------
Date: Wed, 19 Apr 2006 21:28:51 +0200
From: Asterbing <no@thanks.com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <MPG.1eb0adc536cc4f64989806@news.tiscali.fr>
In article <Xns97AA916DBEDB4castleamber@130.133.1.4>,
john@castleamber.com says...
> You mean it reads until it detects that the max size has been reached?
> Yes, that's what I expect, since one can keep streaming bytes, and only
> when the max has been reached the script knows it was too much.
>
When CONTENT_LENGTH not given during request, server has to compute it
from real data received in STDIN : so, in this case how does CGI.pm is
able to stop receiving to STDIN precisely when $CGI::POST_MAX is reached
?
Not sure it's able to do that. What do you think ?
------------------------------
Date: 19 Apr 2006 19:38:20 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <Xns97AA94E646CAcastleamber@130.133.1.4>
Asterbing <no@thanks.com> wrote:
> In article <Xns97AA8023D74CDcastleamber@130.133.1.4>,
> john@castleamber.com says...
>> $CGI::POST_MAX
>>
>> If set to a non-negative integer, this variable puts a ceiling on
>> the
>> size of POSTings, in bytes. If CGI.pm detects a POST that is greater
>> than the ceiling, it will immediately exit with an error message.
>> This value will affect both ordinary POSTs and multipart POSTs,
>> meaning that it limits the maximum size of file uploads as well. You
>> should set this to a reasonably high value, such as 1 megabyte.
>>
>
> Without CGI.pm !
Why? Look how "they" do it, and copy it.
> However, reading what you posted from CGI.pm help, it seems that
> CGI.pm doesn't really limit the file size precisely but rather the
> entire POSTed data. So, how if I want to be free to choose the file
> limit not as 1MB but as 5KB ?
Good question, set it to 50KB, and check the actual filesize.
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: Wed, 19 Apr 2006 15:42:47 -0400
From: Denver <××DBraughler××@××bwcc·com>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <124d4lpmil2vd65@corp.supernews.com>
Asterbing wrote:
> xhoster wrote:
>> John Bokma wrote:
>> > Ok, so your question actually is: how do I avoid the uploading of big
>> > files:
>> >
>> > $CGI::POST_MAX
>> >
>> > If set to a non-negative integer, this variable puts a ceiling on the
>> > size of POSTings, in bytes. If CGI.pm detects a POST that is greater than
>> > the ceiling, it will immediately exit with an error message.
>>
>> That should probaby be changed. It does not immediately exit with
>> an error message. It first reads (and discards) the entire contents
>> of the POST, which apparently the OP doesn't want to happen
It would make sense to me to send an error message, close the connection, and exit.
Otherwise, a DoS attack indeed keeps streaming bits to the server.
>> it doesn't exit at all. It causes param to return an empty param list, and it causes
>> cgi_error to return an error message--no exiting involved.
>
> OK, so it doesn't specifically limit the size of uploadable file
> (but size of entire POST)
> and it doesn't avoid sending of entire POST data from web browser to server's STDIN ?
STDIN isn't the right term.
Apparently the incoming data continue filling the TCP receive buffer for that socket.
------------------------------
Date: 19 Apr 2006 19:52:30 GMT
From: xhoster@gmail.com
Subject: Re: How to find uploaded data size from content-length
Message-Id: <20060419160549.155$o1@newsreader.com>
John Bokma <john@castleamber.com> wrote:
> xhoster@gmail.com wrote:
>
> > John Bokma <john@castleamber.com> wrote:
> >> Asterbing <no@thanks.com> wrote:
> >>
> >> > In article <Xns97AA6D15AEC7Fcastleamber@130.133.1.4>,
> >> > john@castleamber.com says...
> >> >> Why not -s filename assuming you store it in a file system?
> >> >
> >> > Because I would like to avoid too big files
> >>
> >> Ok, so your question actually is: how do I avoid the uploading of big
> >> files:
> >>
> >> $CGI::POST_MAX
> >>
> >> If set to a non-negative integer, this variable puts a ceiling on
> >> the
> >> size of POSTings, in bytes. If CGI.pm detects a POST that is greater
> >> than the ceiling, it will immediately exit with an error message.
> >
> > That should probaby be changed. It does not immediately exit with
> > an error message. It first reads (and discards) the entire contents
> > of the POST, which apparently the OP doesn't want to happen althought
> > it is kind of hard to figure out exactly what he wants. Also, it
> > doesn't exit at all. It causes param to return an empty param list,
> > and it causes cgi_error to return an error message--no exiting
> > involved.
>
> You mean it reads until it detects that the max size has been reached?
No. It compares CONTENT_LENGTH to POST_MAX. If CONTENT_LENGTH is greater
than POST_MAX, then it reads the entire post, but doesn't do anything with
it (doesn't parse it, doesn't save it to disk, just reads and throws away
in chunks.) If CONTENT_LENGTH is less than POST_MAX, it reads the post
and parses it (saving parts of it to disk, if appropriate.)
> Yes, that's what I expect, since one can keep streaming bytes, and only
> when the max has been reached the script knows it was too much.
But AFAICT, it doesn't do it this way. It seems to trust CONTENT_LENGTH
absolutely, and if CONTENT_LENGTH is wrong it does nothing to detect this.
> The second part: if the documentation is wrong, it must be fixed. Did you
> submit this?
I haven't yet. I'm not sure how I would recommend changing it. The
read-but-discard thing may be an (only sometimes important) implementation
detail that does not need to be documented. The "immediate exit" is
clarified later on the documention, and I'm not sure how to clarify here
also without causing bloat.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 19 Apr 2006 20:00:23 GMT
From: xhoster@gmail.com
Subject: Re: How to find uploaded data size from content-length
Message-Id: <20060419161342.039$bv@newsreader.com>
Asterbing <no@thanks.com> wrote:
> In article <Xns97AA8023D74CDcastleamber@130.133.1.4>,
> john@castleamber.com says...
> > $CGI::POST_MAX
> >
> > If set to a non-negative integer, this variable puts a ceiling on
> > the size of POSTings, in bytes. If CGI.pm detects a POST that is
> > greater than the ceiling, it will immediately exit with an error
> > message. This value will affect both ordinary POSTs and multipart
> > POSTs, meaning that it limits the maximum size of file uploads as well.
> > You should set this to a reasonably high value, such as 1 megabyte.
> >
>
> Without CGI.pm !
>
> However, reading what you posted from CGI.pm help, it seems that CGI.pm
> doesn't really limit the file size precisely but rather the entire
> POSTed data. So, how if I want to be free to choose the file limit not
> as 1MB but as 5KB ?
Do you really consider 5KB to be a denial of service attack?
Set one limit on the whole post of, say, 10MB, to prevent DoS attacks.
If the size is over 10MB, send a nasty message about DoS not being welcome.
If it is under 10MB, process it, save the upload to a temp file, and
check its size. If the size is more than 5KB, send a polite message
saying the file was a tad too big, and delete the temp file. Otherwise,
do whatever it is you want to do.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Wed, 19 Apr 2006 16:29:26 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <m21wvt5mxl.fsf@Sherm-Pendleys-Computer.local>
Asterbing <no@thanks.com> writes:
> Because when CONTENT_LENGTH has been informed by server itself after
> receiving of entire POST, I can effectively read STDIN, extract uploaded
> data and do the substraction.
Don't read from stdin. Read from the filehandle you get from CGI.pm.
> Say, I wish to avoid any upload (I mean write on server, since data may
> already be in STDIN) above 1MB, how to proceed ?
Wish for something that's possible.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Wed, 19 Apr 2006 16:33:25 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: How to find uploaded data size from content-length
Message-Id: <m2wtdl486i.fsf@Sherm-Pendleys-Computer.local>
Asterbing <no@thanks.com> writes:
> In article <Xns97AA916DBEDB4castleamber@130.133.1.4>,
> john@castleamber.com says...
>> You mean it reads until it detects that the max size has been reached?
>> Yes, that's what I expect, since one can keep streaming bytes, and only
>> when the max has been reached the script knows it was too much.
>>
>
> When CONTENT_LENGTH not given during request, server has to compute it
> from real data received in STDIN
The server isn't receiving data from stdin, it's receiving it from a net-
work connection.
> : so, in this case how does CGI.pm is
> able to stop receiving to STDIN precisely when $CGI::POST_MAX is reached
It doesn't make the client stop sending data, it just ignores anything
beyond POST_MAX.
> Not sure it's able to do that. What do you think ?
It can and does stop receiving data. Your confusion is the result of
thinking that it *also* causes the client to stop *sending* data.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: 19 Apr 2006 20:20:59 GMT
From: xhoster@gmail.com
Subject: Re: How to find uploaded data size from content-length
Message-Id: <20060419163418.712$cu@newsreader.com>
Asterbing <no@thanks.com> wrote:
> In article <20060419144430.442$mT@newsreader.com>, xhoster@gmail.com
> says...
> > I have no idea why you think you need to do this.....
> >
>
> Because when CONTENT_LENGTH has been informed by server itself after
> receiving of entire POST, I can effectively read STDIN, extract uploaded
> data and do the substraction.
Once you've extracted the data, why would you need to do the subtraction?
Once you've extracted the data, you already have the data, just ask the
data how big it is. I thought the whole point was to avoid extracting the
data in the first place.
>
> But, when CONTENT_LENGTH comes from original request, how to proceed ?
>
> Say, I wish to avoid any upload (I mean write on server, since data may
> already be in STDIN) above 1MB, how to proceed ?
You have enough memory to load a 1 MB of non-file-upload form-data into
memory, but not enough disk to temporarily save 1 MB of file-upload data?
That just doesn't make sense. If you computer will break with 1MB of
posted data, don't allow that size of post, whether it is file upload or
not. If your computer won't break, then what's the problem? Uploaded it,
ask how big each form-part is, and do the appropriate thing.
Having said that, you could hack/subclass the read_multipart method
of CGI.pm to have it, at a certain size, stop copying the data into the
file, something like:
while (defined($data = $buffer->read)) {
if (defined $self->{'.upload_hook'})
{
$totalbytes += length($data);
&{$self->{'.upload_hook'}}($filename ,$data, $totalbytes,
$self->{'.upload_data'});
}
##print $filehandle $data;
print $filehandle $data unless $totalbytes > $FOO::Asterbing_size;
}
Of course, you would have to set a flag or something so that you know that
this has happened.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Wed, 19 Apr 2006 20:18:21 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Term::ReadKey on Win? 5.005 vs 5.8.8?
Message-Id: <e265ud$rml$1@agate.berkeley.edu>
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dr.Ruud
<rvtol+news@isolution.nl>], who wrote in article <e25nfr.1a0.1@news.isolution.nl>:
> > perl -MTerm::ReadKey
> > -wle "open $in, '+< CONIN$' or die;
> > ReadMode 4, $in;
> > $|=1;
> > print ord while defined($_=getc)"
> I had to change that to
> perl -MTerm::ReadKey
> -wle 'open ($in, "+< /dev/tty") or die $!;
Well, I'm not interested in /dev/tty, only in CONIN$.
> ReadMode 4, $in;
> $|=1; print ord while defined($_=getc) and 3!=ord;
My understanding is that Control-Break should stop the application on Win.
> ReadMode 0, $in'
Actually, I do not know; does Term::ReadKey changes the state of TTY
for the parent process on Win*?
> to make it do anything, and to be able to orderly stop it.
> (perl, v5.8.6 built for i386-freebsd-64int)
Thanks,
Ilya
------------------------------
Date: Wed, 19 Apr 2006 14:08:24 -0700
From: "Mothra" <mothra@nowhereatall.com>
Subject: Re: Term::ReadKey on Win? 5.005 vs 5.8.8?
Message-Id: <4446ae82$1@usenet.ugs.com>
Hi Ilya,
Ilya Zakharevich wrote:
> I'm trying to design a workaround for Perl PerlIO bugs...
>
> Could people with working Term::ReadKey determine what happens on
> pressing Enter key (possbly many times, if needed)? E.g., please run
> both
>
> perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die; binmode $in
> or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc)"
> perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die;
> ReadMode 4, $in; $|=1; print ord while defined($_=getc)"
>
> (one with binmode, another without). If possible, use pre-5.6 Perl
> and one of the current Perls, 5.8.7 and 5.8.8. Especially interesting
> is to know how many Enter keypresses are needed to get "some action",
> and how many lines are printed when "an action" happens.
>
> A lot of thanks,
> Ilya
D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open $in, '+< CON
' or die; $in or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc
13
13
13
255
D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open $in, '+< CON
' or die; binmode $in or die; ReadMode 4, $in; $|=1; print ord while defined
=getc)"
13
13
13
255
D:\perl_modules\TermReadKey-2.30>perl -v
This is perl, v5.8.6 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)
Copyright 1987-2004, Larry Wall
I had to press enter once in order for it to work.
Hope this helps
Mothra
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9176
***************************************
