Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of jochen.wiedmann@gmail.com
 designates 66.249.82.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=dpIA3rjZFgjE8iA+UK7ZgCaVBa6rChKzqmMGyldfqgKtg7dqcG2OSOUuxLb+ac4YqDpcCvSs+X+3ld+fQ8geVDKzNVkmCIcAOcByZ9nYTcb5PnbJLqJmstDtKEmFQiPMvTIhE5QpcIEKUfvhCmpKZWoVJbT4/hl1G7zeQy0S+DA=
Message-ID: <e75283b10708292313i677c439cqaf735deb3ec2343b@mail.gmail.com>
Date: Thu, 30 Aug 2007 08:13:10 +0200
From: "Jochen Wiedmann" <jochen.wiedmann@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: FileUploadBase.setFileSizeMax &
 MultipartStream.ItemInputStream.makeAvailable()
In-Reply-To: <6BA54373-8FA1-4D46-BC8C-0E1CDCF20BC4@alum.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6BA54373-8FA1-4D46-BC8C-0E1CDCF20BC4@alum.mit.edu>

On 8/30/07, Eric Hermanson <eric@alum.mit.edu> wrote:

> setFileSizeMax is apparently intended to prevent the file upload if
> the file about to be uploaded is larger than a given size.  However,
> the exception does not get processed until AFTER the entire file is
> uploaded to the server (thereby defeating the purpose of the limit).

That's not the case. If you are setting this property, then the file
items input stream is wrapped by an instance of LimitedInputStream.
That instance raises the exception as soon as more than fileSizeMax
bytes are returned to the caller. It may certainly look so, if the
uploaded file is, for example, 10.5 MB and the limit is 10MB. Apart
from that, it is quite possible that the exception is ignored by the
browser and the browser continues to shuffle data to the server. But
that's nothing we can control.

I admit, that an additional improvement could be made: We might check,
if the file items headers (as opposed to the request headers) contain
a content-length entry, which exceeds the limit. However, I admit that
this would help, because I've seen few cases where the item does
contain a content-length header. Patches welcome, though.

> I went into the debugger and noticed that
>
>         MultipartStream.ItemInputStream.close()
>
> is calling
>
>         MultipartStream.ItemInputStream.makeAvailable()
>
> and the call to InputStream.read() in that method is actually what's
> causing the entirety of the oversized file upload data to be
> incorrectly read.

This may be the case, if you haven't read all the data before invoking
the close() method.


Jochen


-- 
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org