Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > existence and size of client file

Reply
Thread Tools

existence and size of client file

 
 
Joe Smith
Guest
Posts: n/a
 
      04-15-2006
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
 
Reply With Quote
 
 
 
 
Joe Smith
Guest
Posts: n/a
 
      04-15-2006
Asterbing wrote:
> In article <bkP%f.28$yQ.0@trnddc07>, http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
 
 
 
Joe Smith
Guest
Posts: n/a
 
      04-15-2006
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
 
Reply With Quote
 
Asterbing
Guest
Posts: n/a
 
      04-16-2006
In article <qyX%f.93$JY5.55@trnddc01>, (E-Mail Removed) says...
> Ok, then to answer your particular question: No, the programming language
> Perl does not know anything at all about HTTP or CGI. Nothing, nada, zilch,
> rien. Absolutely nothing. Had you checked "perldoc perlfunc" you probably
> would have noticed that yourself.
>


Oh, merci, thanks, spassiba, danke. Then, I'll surely have to check $ENV
{'CONTENT_LENGTH'} after form POSTing, then parse to find data and read
toward buffer before to write in a new file server target... All of this
without any line of Perl code even if my first line is "#!/usr/bin/perl
-T".

Huuuu, what a difficult thing
 
Reply With Quote
 
Asterbing
Guest
Posts: n/a
 
      04-16-2006
In article <(E-Mail Removed)>, (E-Mail Removed)
says...
> 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?
>


Understood
 
Reply With Quote
 
Asterbing
Guest
Posts: n/a
 
      04-16-2006
In article <(E-Mail Removed)>, (E-Mail Removed) says...
> 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.
>


OK Thus, even if I'm checking content-length, data file has already
been sent : right ?
 
Reply With Quote
 
Asterbing
Guest
Posts: n/a
 
      04-16-2006
In article <(E-Mail Removed)>, (E-Mail Removed) says...
> 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.
>


Yes, it was, after refexion, what I expected. It's a pity !
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      04-16-2006
Asterbing wrote:
> In article <(E-Mail Removed)>, (E-Mail Removed) says...
>> 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.
>>

>
> OK Thus, even if I'm checking content-length, data file has
> already been sent : right ?


Maybe, maybe not. It depends on your web server, the speed of the
connection between the client and the server, and maybe some other
things.

The client sends an HTTP POST request, which contains the URL, the
Content-Type and the Content-Length in the header and the data file(s)
as well as any other form data in the body.

The server receives the request and has to read the header to know what
to do with the request and to fill in various environment variables
before invoking the CGI script.

Then the server has inkove the CGI script so that the CGI script can
read the body from STDIN. There are (at least) three ways to do that:

1) if the server has read *only* the header (which is difficult to
ensure in a efficient manner) it can simply pass the open socket to
the script.

2) It can also set up a pair of pipes or a socket to the script and send
everything it gets from the client to the script and vice versa.

3) Finally, it could read the rest of the body, save it to a temporary
file and invoke the script with stdin redirected to that file.

I believe most web servers use option 2 or maybe 1 with some trickery.

In these cases, the script is invoked as soon as the web server has
received and parsed the header of the request. For a large request, this
means that most of the content has not yet been sent by the client.

So theoretically, your script can just look at $ENV{HTTP_CONTENT_LENGTH}
before reading anything and - if it decides that the content length is
too long to process - send back an error message and exit.

With option 2, the web server may still read the rest of the request and
discard it. Or it may pass the output from the script to the client and
close the connection. In this case the client will notice that the
connection is broken and stop uploading. So you save some bandwidth.
However, if you do that, be sure to test it thoroughly with as many
browsers as possible. Some may display the message you sent back. Some
may additionally display a message that the connection was broken. Some
may only display this message and discard yours. Some may even retry the
upload automatically (early Mozilla versions used to do this).

None of this has anything to do with perl, of course.

hp

--
_ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
|_|_) | Sysadmin WSR/LUGA |
| | | (E-Mail Removed) | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |
 
Reply With Quote
 
Asterbing
Guest
Posts: n/a
 
      04-17-2006
In article <(E-Mail Removed)>, (E-Mail Removed) says...
> None of this has anything to do with perl, of course.
>


Not comp.lang.perl, we're agree, but not comp.lang.perl.misc which, by
design, incorporates, implicitely, indirect questions, it's not so sure


However, thanks for your long and accurate reply, Peter.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
distutils - script install check file existence before copy? bwooster47@gmail.com Python 0 03-04-2007 03:22 AM
mega pixels, file size, image size, and print size - Adobe Evangelists Frank ess Digital Photography 0 11-14-2006 05:08 PM
what is the quickest way to check if I have write permissions to and existence of the file puzzlecracker C++ 4 10-31-2005 12:45 AM
Checking fprintf for errors and testing for existence of a file Jim Hunter C Programming 3 03-06-2005 05:29 PM
Checkup: better way to test for file existence? Matt C++ 14 02-22-2005 12:15 PM



Advertisments