By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,536 Members | 1,504 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,536 IT Pros & Developers. It's quick & easy.

Checking File Size Before Upload

P: n/a
Hi all,

I am not a developer, but I work with several and am posting this for
them. We are trying to determine whether it is possible to check the
size of a file before a user uploads it.

Everything I've read suggests that this is impossible (or at least very
difficult) in PHP, and this makes sense for a server-side language.
What gives me pause, however, is the fact that when a user tries to
upload a file larger than the max file size we allow, an error appears
in our error log immediately -- yet the upload continues.

So somehow PHP must be recognizing that the file is too big well before
it's been uploaded. The question is how -- and how do we make the leap
from that recognition to an immediate halt of the upload?

Aug 22 '06 #1
Share this Question
Share on Google+
19 Replies


P: n/a
On 22 Aug 2006 14:59:35 -0700, "jeremyz" <je*********@gmail.comwrote:
>I am not a developer, but I work with several and am posting this for
them. We are trying to determine whether it is possible to check the
size of a file before a user uploads it.

Everything I've read suggests that this is impossible (or at least very
difficult) in PHP, and this makes sense for a server-side language.
What gives me pause, however, is the fact that when a user tries to
upload a file larger than the max file size we allow, an error appears
in our error log immediately -- yet the upload continues.

So somehow PHP must be recognizing that the file is too big well before
it's been uploaded. The question is how -- and how do we make the leap
from that recognition to an immediate halt of the upload?
The browser may send a Content-length header with the file upload. PHP can
read this immediately, since it's right at the start of the request, and so can
produce an error in the log if it's too big.

However, there's no way for PHP to send a response to the browser yet, because
the content of the file is part of the HTTP request. Its choices are to either
unceremoniously dump the connection without a response (which it doesn't do,
for obvious reasons, although the HTTP protocol does allow this), or wait until
the request has finished so it can send a response back with an error message.

AFAIK this is a limitation of the HTTP protocol and so cannot be worked
around.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Aug 22 '06 #2

P: n/a
Andy Hassall wrote:
However, there's no way for PHP to send a response to the browser yet, because
the content of the file is part of the HTTP request. Its choices are to either
unceremoniously dump the connection without a response (which it doesn't do,
for obvious reasons, although the HTTP protocol does allow this), or wait until
the request has finished so it can send a response back with an error message.

AFAIK this is a limitation of the HTTP protocol and so cannot be worked
around.
I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received. In theory, the
server can send status code 100 to accept the request or a 4xx error
code to reject it. That's not how it's implemented in the browsers
though, AFAIK.

The browser should pass the size of the request to onSubmit if you ask
me. Sometimes I wish HTML hadn't just stopped progressing completely...

Aug 23 '06 #3

P: n/a
Andy Hassall wrote:
However, there's no way for PHP to send a response to the browser yet, because
the content of the file is part of the HTTP request. Its choices are to either
unceremoniously dump the connection without a response (which it doesn't do,
for obvious reasons, although the HTTP protocol does allow this), or wait until
the request has finished so it can send a response back with an error message.

AFAIK this is a limitation of the HTTP protocol and so cannot be worked
around.
I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received. In theory, the
server can send status code 100 to accept the request or a 4xx error
code to reject it. That's not how it's implemented in the browsers
though, AFAIK.

The browser should pass the size of the request to onSubmit if you ask
me. Sometimes I wish HTML hadn't just stopped progressing completely...

Aug 23 '06 #4

P: n/a
Chung Leong wrote:
Andy Hassall wrote:
> However, there's no way for PHP to send a response to the browser yet, because
the content of the file is part of the HTTP request. Its choices are to either
unceremoniously dump the connection without a response (which it doesn't do,
for obvious reasons, although the HTTP protocol does allow this), or wait until
the request has finished so it can send a response back with an error message.

AFAIK this is a limitation of the HTTP protocol and so cannot be worked
around.

I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received. In theory, the
server can send status code 100 to accept the request or a 4xx error
code to reject it. That's not how it's implemented in the browsers
though, AFAIK.

The browser should pass the size of the request to onSubmit if you ask
me. Sometimes I wish HTML hadn't just stopped progressing completely...
Hi,

try using a hidden max file size field to pass to php

<input type="hidden" name="MAX_FILE_SIZE" value="2048576">

Cheers,

Luke.

Aug 23 '06 #5

P: n/a
Luke - ea********@gmail.com wrote:
Chung Leong wrote:
>Andy Hassall wrote:
>> However, there's no way for PHP to send a response to the browser
yet, because
the content of the file is part of the HTTP request. Its choices are
to either
unceremoniously dump the connection without a response (which it
doesn't do,
for obvious reasons, although the HTTP protocol does allow this), or
wait until
the request has finished so it can send a response back with an error
message.

AFAIK this is a limitation of the HTTP protocol and so cannot be worked
around.

I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received. In theory, the
server can send status code 100 to accept the request or a 4xx error
code to reject it. That's not how it's implemented in the browsers
though, AFAIK.

The browser should pass the size of the request to onSubmit if you ask
me. Sometimes I wish HTML hadn't just stopped progressing completely...

Hi,

try using a hidden max file size field to pass to php

<input type="hidden" name="MAX_FILE_SIZE" value="2048576">

Cheers,

Luke.
Just found a reference to it. http://uk2.php.net/features.file-upload
Aug 23 '06 #6

P: n/a
On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received
Isn't it implied by HTTP 1.1 sec 6:

http://www.w3.org/Protocols/rfc2616/...sec6.html#sec6
"6 Response

After receiving and interpreting a request message, a server responds with an
HTTP response message. "

The key being "After"?

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Aug 23 '06 #7

P: n/a
Andy Hassall wrote:
On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received

Isn't it implied by HTTP 1.1 sec 6:

http://www.w3.org/Protocols/rfc2616/...sec6.html#sec6
"6 Response

After receiving and interpreting a request message, a server responds with an
HTTP response message. "

The key being "After"?
But the existence of status code 100 implies a interim response can be
sent. Look at 8.2.3:

The purpose of the 100 (Continue) status (see section 10.1.1) is to
allow a client that is sending a request message with a request body to
determine if the origin server is willing to accept the request (based
on the request headers) before the client sends the request body. In
some cases, it might either be inappropriate or highly inefficient for
the client to send the body if the server will reject the message
without looking at the body.

[http://www.w3.org/Protocols/rfc2616/...html#sec8.2.3]

So the desired behavior is defined in the specs. I don't know if it's
widely implemented though.

Aug 23 '06 #8

P: n/a
On 23 Aug 2006 13:17:34 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>Andy Hassall wrote:
>On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received

Isn't it implied by HTTP 1.1 sec 6:

http://www.w3.org/Protocols/rfc2616/...sec6.html#sec6
"6 Response

After receiving and interpreting a request message, a server responds with an
HTTP response message. "

The key being "After"?

But the existence of status code 100 implies a interim response can be
sent. Look at 8.2.3:

The purpose of the 100 (Continue) status (see section 10.1.1) is to
allow a client that is sending a request message with a request body to
determine if the origin server is willing to accept the request (based
on the request headers) before the client sends the request body. In
some cases, it might either be inappropriate or highly inefficient for
the client to send the body if the server will reject the message
without looking at the body.

[http://www.w3.org/Protocols/rfc2616/...html#sec8.2.3]

So the desired behavior is defined in the specs. I don't know if it's
widely implemented though.
Ah! Interesting - thanks.

So PHP could - in theory - send the response back as a 417 and populate
$_FILES with a suitable error.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Aug 23 '06 #9

P: n/a
Luke - ea********@gmail.com wrote:
Luke - ea********@gmail.com wrote:
>Chung Leong wrote:
>>Andy Hassall wrote:
However, there's no way for PHP to send a response to the browser
yet, because
the content of the file is part of the HTTP request. Its choices are
to either
unceremoniously dump the connection without a response (which it
doesn't do,
for obvious reasons, although the HTTP protocol does allow this), or
wait until
the request has finished so it can send a response back with an
error message.

AFAIK this is a limitation of the HTTP protocol and so cannot be
worked
around.

I don't think the HTTP protocol specs mandates that a response can only
be sent after the request body has been fully received. In theory, the
server can send status code 100 to accept the request or a 4xx error
code to reject it. That's not how it's implemented in the browsers
though, AFAIK.

The browser should pass the size of the request to onSubmit if you ask
me. Sometimes I wish HTML hadn't just stopped progressing completely...

Hi,

try using a hidden max file size field to pass to php

<input type="hidden" name="MAX_FILE_SIZE" value="2048576">

Cheers,

Luke.
Just found a reference to it. http://uk2.php.net/features.file-upload
Not sure if this holds truth in general but: on my host's
(Centos/Apache2.0.50/PHP4.3.4) server, using firefox as a browser (on
Gentoo) the MAX_FILE_SIZE field is not acknowledged by either the server
OR the browser. It simply sends the request regardless and than we're
back at OP's original issue.

I believe some choose a javascript solution to have the client check the
filesize. Not sure how (well) this works.

Sh
Aug 23 '06 #10

P: n/a
Andy Hassall wrote:
Ah! Interesting - thanks.

So PHP could - in theory - send the response back as a 417 and populate
$_FILES with a suitable error.
In theory. I have never seen IE sending an expect 100-continue header.
Maybe Firefox does. I doubt it though. In a way it is a limitation of
the specs, as I don't need a pragmatic way by which this feature could
be implemented. Since existing servers do not send the 100 Continue
message, the browser has to rely on some kind of a timeout. That would,
of course, slow things down significantly. What is needed is a header
for server to communicate to the client that it's capable of emitting a
100-continue. Then again, come to think of it, the whole thing is
really useless, since there's no information in the request headers
that tells you the file size or other criteria by which you might
reject the request body.

It's easier to handle this on the client side. The input=file element
should expose the size of the file selected. An element for uploading
multiple files would be nice too. That and a onSubmitProgress event for
monitoring the upload progress... The lack of innovation really sucks.

Aug 23 '06 #11

P: n/a
"Schraalhans Keukenmeester" <fi********************@xsfourall.ennelpíse v
diskusním príspevku news:44**********************@news.xs4all.nl...
Luke - ea********@gmail.com wrote:
I believe some choose a javascript solution to have the client check the
filesize. Not sure how (well) this works.
My idea:

<body>
[... some code ...]
<script type="text/javascript></script>
<noscript>You have not enabled Javascript! Maybe file uploading will not
work correctly.</noscript>
[... some code ...]
</body>

--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
Aug 24 '06 #12

P: n/a
Rik
Chung Leong wrote:
It's easier to handle this on the client side. The input=file element
should expose the size of the file selected. An element for uploading
multiple files would be nice too. That and a onSubmitProgress event
for monitoring the upload progress... The lack of innovation really
sucks.

[AOL]
My sentiments exactly.
[/AOL]

Allthough, server-side checking will always have to be done, it's immensely
irritating when:
1. A user waits several minutes to upload something and only then gets the
message the file was to big.
2. Laymen claim you upload doesn't work when they just don't wait untill
it's uploaded. (allthough I usually crudely fix this by placing a message
'uploading..' in the page by js on the onsubmit event.

--
Grtz,

Rik Wasmus
Aug 24 '06 #13

P: n/a
Rik wrote:
Allthough, server-side checking will always have to be done, it's immensely
irritating when:
1. A user waits several minutes to upload something and only then gets the
message the file was to big.
2. Laymen claim you upload doesn't work when they just don't wait untill
it's uploaded. (allthough I usually crudely fix this by placing a message
'uploading..' in the page by js on the onsubmit event.
Often times we run into the opposite problem--users sitting there
waiting for the upload to finish when it has died.

Aug 24 '06 #14

P: n/a
On 23 Aug 2006 15:46:52 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>In theory. I have never seen IE sending an expect 100-continue header.
Maybe Firefox does.
Nope, doesn't.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Aug 24 '06 #15

P: n/a
Petr Vileta wrote:
"Schraalhans Keukenmeester" <fi********************@xsfourall.ennelpíse v
diskusním príspevku news:44**********************@news.xs4all.nl...
>Luke - ea********@gmail.com wrote:
I believe some choose a javascript solution to have the client check the
filesize. Not sure how (well) this works.

My idea:

<body>
[... some code ...]
<script type="text/javascript></script>
<noscript>You have not enabled Javascript! Maybe file uploading will not
work correctly.</noscript>
[... some code ...]
</body>

As far as I can tell (via Google), it is not even possible with
JavaScript anyway (unless the browser uses and allows Active-X).

--
*****************************
Chuck Anderson • Boulder, CO
http://www.CycleTourist.com
Everyone's journey should be different,
so that we all are enriched
in new and endless ways
*****************************
Aug 24 '06 #16

P: n/a
On 22 Aug 2006 14:59:35 -0700, "jeremyz" <je*********@gmail.comwrote:
>I am not a developer, but I work with several and am posting this for
them. We are trying to determine whether it is possible to check the
size of a file before a user uploads it.

Everything I've read suggests that this is impossible (or at least very
difficult) in PHP, and this makes sense for a server-side language.
What gives me pause, however, is the fact that when a user tries to
upload a file larger than the max file size we allow, an error appears
in our error log immediately -- yet the upload continues.

So somehow PHP must be recognizing that the file is too big well before
it's been uploaded. The question is how -- and how do we make the leap
from that recognition to an immediate halt of the upload?
There's this: http://pdoru.from.ro/

... which is a file upload progress patch for PHP. The demo opens a popup
window that monitors the upload taking place in the first window.

Possibly this could be modified so the second window uses javascript to abort
the upload in the first window? Not sure. Not very nice, but the alternatives
are sparse.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Aug 24 '06 #17

P: n/a
Petr Vileta wrote:
>"Schraalhans Keukenmeester" <fi********************@xsfourall.ennelpíse
v diskusním príspevku news:44**********************@news.xs4all.nl...
>>Luke - ea********@gmail.com wrote:
I believe some choose a javascript solution to have the client check the
filesize. Not sure how (well) this works.

My idea:

<body>
[... some code ...]
<script type="text/javascript></script>
<noscript>You have not enabled Javascript! Maybe file uploading will not
work correctly.</noscript>
[... some code ...]
</body>

As far as I can tell (via Google), it is not even possible with JavaScript
anyway (unless the browser uses and allows Active-X).

--
*****************************
Chuck Anderson • Boulder, CO
Yes. Maybe browser put "Content-Length: ???" into HTTP header and PHP can
read it, but not in all cases.
I found this for using ActiveX in MSIE:
http://www.jguru.com/faq/view.jsp?EID=330134

--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
Aug 25 '06 #18

P: n/a
Chung Leong schrieb:
>
It's easier to handle this on the client side. The input=file element
should expose the size of the file selected. An element for uploading
multiple files would be nice too. That and a onSubmitProgress event for
monitoring the upload progress... The lack of innovation really sucks.
In cases where you don't mind using a Java applet for upload, check out
http://www.radinks.com/upload/.

Provides status bar, choice for HTTP or FTP upload, multiple uploads,
client-side image scaling, is really easy to use, and also not too hard
to implement. The basic version is free, the most sophisticated one
about 40 US$.

I usually don't do advertisement, but this one is one of my favorite
pieces of software...

Markus
Aug 25 '06 #19

P: n/a
jeremyz wrote:
<snip>
What gives me pause, however, is the fact that when a user tries to
upload a file larger than the max file size we allow, an error appears
in our error log immediately -- yet the upload continues.
<snip>

I don't think that will happen if you configure Apache with
LimitRequestBody
<http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody>

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Aug 26 '06 #20

This discussion thread is closed

Replies have been disabled for this discussion.