«

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

Asterbing wrote:
> In article <bkP%f.28$yQ.0@trnddc07>, 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

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

In article <qyX%f.93$JY5.55@trnddc01>, 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

In article <lbmdnb->,
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

In article <3qqdnTP9wK4AytzZRVn->, 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 ?

In article <UMCdnZS_OZ55xtzZRVn->, 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 !

Asterbing wrote:
> In article <3qqdnTP9wK4AytzZRVn->, 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 |
| | | | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |

In article <>, hjp- 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.