Checking File Size Before Upload

[jeremyz]

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?

[Andy Hassall]

Re: Checking File Size Before Upload

On 22 Aug 2006 14:59:35 -0700, "jeremyz" <jeremy.zorn@gm ail.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 :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Chung Leong]

Re: Checking File Size Before Upload

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...

[Chung Leong]

Re: Checking File Size Before Upload

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...

[Luke - eat.lemons@gmail.com]

Re: Checking File Size Before Upload

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
>unceremoniousl y 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.

[Luke - eat.lemons@gmail.com]

Re: Checking File Size Before Upload

Luke - eat.lemons@gmai l.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
>>unceremonious ly 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

[Andy Hassall]

Re: Checking File Size Before Upload

On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <chernyshevsky@ hotmail.comwrot e:

>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/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 :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Chung Leong]

Re: Checking File Size Before Upload

Andy Hassall wrote:

On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <chernyshevsky@ hotmail.comwrot e:
>

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/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.

[Andy Hassall]

Re: Checking File Size Before Upload

On 23 Aug 2006 13:17:34 -0700, "Chung Leong" <chernyshevsky@ hotmail.comwrot e:

>Andy Hassall wrote:

>On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <chernyshevsky@ hotmail.comwrot e:
>>

>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 :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Schraalhans Keukenmeester]

Re: Checking File Size Before Upload

Luke - eat.lemons@gmai l.com wrote:

Luke - eat.lemons@gmai l.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
>>>unceremoniou sly 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

[Chung Leong]

Re: Checking File Size Before Upload

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 onSubmitProgres s event for
monitoring the upload progress... The lack of innovation really sucks.

[Petr Vileta]

Re: Checking File Size Before Upload

"Schraalhan s Keukenmeester" <firstname_dot_ lastname@xsfour all.ennelpíse v
diskusním príspevku news:44ecd362$1 $4519$e4fe514c@ news.xs4all.nl. ..

Luke - eat.lemons@gmai l.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.)

[Rik]

Re: Checking File Size Before Upload

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 onSubmitProgres s 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

[Chung Leong]

Re: Checking File Size Before Upload

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.

[Andy Hassall]

Re: Checking File Size Before Upload

On 23 Aug 2006 15:46:52 -0700, "Chung Leong" <chernyshevsky@ hotmail.comwrot e:

>In theory. I have never seen IE sending an expect 100-continue header.
>Maybe Firefox does.

Nope, doesn't.

--
Andy Hassall :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool