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]

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

[Chung Leong]

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]

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]

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]

Luke - ea********@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]

On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <ch***********@ 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"?

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

[Chung Leong]

Andy Hassall wrote:

On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <ch***********@ 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.

[Andy Hassall]

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

>Andy Hassall wrote:

>On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <ch***********@ 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 :: an**@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Schraalhans Keukenmeester]

Luke - ea********@gmai l.com wrote:

Luke - ea********@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