I would like to prevent files over a certain size from being uploaded. I don't want to check after the fact; I'd like to abort request processing as soon as the content-length is known to be too large.
Is it ok to close the content-stream and error out of initialize-instance on the request? Is there a better way?
Zach
On Wed, 3 May 2006 10:29:05 -0400, Zach Beane xach@xach.com wrote:
I would like to prevent files over a certain size from being uploaded. I don't want to check after the fact; I'd like to abort request processing as soon as the content-length is known to be too large.
Is it ok to close the content-stream and error out of initialize-instance on the request? Is there a better way?
I would assume that it is "OK" in the sense that it doesn't wreak havoc. You'll be caught by the IGNORE-ERRORS in LISTEN-FOR-REQUEST which in turn will close the stream. If you're behind Apache, it will then as a result of this sooner or later close the stream to the client which is still trying to send stuff. Of course, there's no way to re-use these streams and/or to send a message to the client.
It's not pretty, though, but OTOH I think there /is/ no pretty way of doing this. Do you want to do this as some kind of anti-DoS measure?
Cheers, Edi.
On Wed, May 03, 2006 at 05:32:26PM +0200, Edi Weitz wrote:
Is it ok to close the content-stream and error out of initialize-instance on the request? Is there a better way?
I would assume that it is "OK" in the sense that it doesn't wreak havoc. You'll be caught by the IGNORE-ERRORS in LISTEN-FOR-REQUEST which in turn will close the stream. If you're behind Apache, it will then as a result of this sooner or later close the stream to the client which is still trying to send stuff. Of course, there's no way to re-use these streams and/or to send a message to the client.
It's not pretty, though, but OTOH I think there /is/ no pretty way of doing this. Do you want to do this as some kind of anti-DoS measure?
Yes, though not an intentional DoS. My application accepts image files and only processes files of a reasonable size. Allowing uploads of very large files only to reject them later in the process consumes CPU, bandwidth, and memory that could be used elsewhere.
I have a local patch for this (the large files were also crashing SBCL, so I needed to do something quickly). If I figure out a nice way to do it, I will send along a TBNL patch too.
Zach
Zach Beane wrote:
On Wed, May 03, 2006 at 05:32:26PM +0200, Edi Weitz wrote:
Yes, though not an intentional DoS. My application accepts image files and only processes files of a reasonable size. Allowing uploads of very large files only to reject them later in the process consumes CPU, bandwidth, and memory that could be used elsewhere.
Could you use Javascript on the client to check the file size before allowing the upload?
Something like the following:
http://www.cs.tut.fi/~jkorpela/forms/file.html#restr
-Luke
On Thu, May 11, 2006 at 07:01:08PM -0700, Luke J Crook wrote:
Zach Beane wrote:
On Wed, May 03, 2006 at 05:32:26PM +0200, Edi Weitz wrote:
Yes, though not an intentional DoS. My application accepts image files and only processes files of a reasonable size. Allowing uploads of very large files only to reject them later in the process consumes CPU, bandwidth, and memory that could be used elsewhere.
Could you use Javascript on the client to check the file size before allowing the upload?
Something like the following:
Hmm, that page seems to suggest that there is no reliable way to do it on the client side.
Zach
-
Edi Weitz -
Luke J Crook -
Zach Beane