[27797] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 9161 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Apr 15 18:05:36 2006

Date: Sat, 15 Apr 2006 15:05:04 -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           Sat, 15 Apr 2006     Volume: 10 Number: 9161

Today's topics:
    Re: existence and size of client file <joe@inwap.com>
    Re: existence and size of client file <joe@inwap.com>
    Re: existence and size of client file <joe@inwap.com>
    Re: Perl script as Windows service fails to run <jeffjones@u-spam-u-die.net>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sat, 15 Apr 2006 13:29:14 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: existence and size of client file
Message-Id: <3qqdnTP9wK4AytzZRVn-uQ@comcast.com>

Asterbing wrote:

> Thus, for example, I would like that John submit a 101MB file and be 
> warn some minutes later, after unuseful 100MB uploading.
> 
> Is there a way to solve this case using the builtin functions available 
> in Perl ?

No.

Perl scripts running on you server can present output to the client;
they do _not_ run on the client.

When the browser (http client) sends a request, your Perl CGI script
is *NOT* running.  Yet.  The only thing that is running is inside
the browser.  If you include JavaScript in your HTML form, then
the JavaScript inside MSIE/Netscape/Firefox/Safari/etc may be able
to do some things, but probably not that.

The builtin functions only apply on the system where Perl is running,
and it is not running on the client.

Let me reiterate:  Under your control is the HTML that you send
to provide a FORM to the client.  You have control of what gets
executed after the POST request reaches your server.  You do not
have control of what happens in between.  The behavior of code
running on the client depends on the software that is installed
on the client, and you do not have control over that.

What you are asking for cannot be solved by Perl, COBOL, FORTRAN,
or anything else _running on the server_.
	-Joe


------------------------------

Date: Sat, 15 Apr 2006 13:34:55 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: existence and size of client file
Message-Id: <lbmdnb-ZwbFuxdzZnZ2dnUVZ_sydnZ2d@comcast.com>

Asterbing wrote:
> In article <bkP%f.28$yQ.0@trnddc07>, jurgenex@hotmail.com says...
>> Again, which part of "this has nothing to do with Perl but only with your 
>> application domain" don't you understand?
> 
> Because, I'm searching if Perl built-in fcts allow to solve my problem. 

If Perl were running on the client, then you could use the language's
built-in functions.  But since Perl is _not_ running on the client
while processing an HTTP CGI request, you cannot use Perl (or any other
programming language) to solve your problem.

Your problem requires a change to the client's behavior, such as by
forcing the end user to download an unsigned plugin and executing it.
You're not expecting that to happen, are you?
	-Joe


------------------------------

Date: Sat, 15 Apr 2006 13:47:28 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: existence and size of client file
Message-Id: <UMCdnZS_OZ55xtzZRVn-pQ@comcast.com>

Asterbing wrote:

> Hum, we have to separate CGI script and CGI script which use CGI.pm. 
> Thus, if I'm reading value POSTed about file field, I just get the 
> client file path and not a file handle like CGI.pm provide.
> 
> Well, then, if I understand your reply, it means I've to use CGI.pm, 
> consider POSTed form contains file data too, and "content-length" is 
> usable to define the file length.
> 
> Right ?

No.  If your intent is to prevent a POST from even being started when
the file size is too big, CGI.pm won't help.  That problem is
impossible to solve in the given problem arena.

If your intent is to abort an HTTP transaction after the POST has
started, you will probably need a modified CGI.pm, since the current
version has this code:

       # avoid unreasonably large postings
       if (($POST_MAX > 0) && ($content_length > $POST_MAX)) {
	# quietly read and discard the post
	  my $buffer;
           my $tmplength = $content_length;
           while($tmplength > 0) {
                  my $maxbuffer = ($tmplength < 10000)?$tmplength:10000;
                  my $bytesread = $MOD_PERL ? $self->r->read($buffer,$maxbuffer) : read(STDIN,$buffer,$maxbuffer);
                  $tmplength -= $bytesread;
           }
           $self->cgi_error("413 Request entity too large");
           last METHOD;
        }

   -Joe


------------------------------

Date: Sat, 15 Apr 2006 18:54:24 GMT
From: Jeffery Jones <jeffjones@u-spam-u-die.net>
Subject: Re: Perl script as Windows service fails to run
Message-Id: <o9g242dfvcet1q7u9punq8d8k6b81d47h7@4ax.com>

On Fri, 14 Apr 2006 17:41:37 -0700, "Kevin Sproule"
<kevinsproule@hotmail.com> wrote:

>Have included the path to the Perl bin folder in the PATH environment
>variable?  eg .  ...;c:\perl\bin

  I've checked and the global environment path variable includes the
Perl bin folder.


------------------------------

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 9161
***************************************


home help back first fref pref prev next nref lref last post