[hunchentoot-devel] Preventing users to upload too big files

[Andrei Stebakov]

The problem is that RFC2388:READ-UNTIL-NEXT-BOUNDARY doesn't know about the
content-length as hunchentoot package doesn't pass this parameter to the
rfc2388:parse-mime function. So again it should be changed in two different
packages.
When I implemented file upload progress bar, I had to modify the hunchentoot
and rfc2388 since only hunchentoot knows about content-length and only
rfc2388 knows how many bytes was read from the stream. Using these two
parameters we can calculate the percentage  of the data that was uploaded to
the server.
I could retrieve the content-length to the client via ajax and do something
in javascript to disrupt the upload, but I doesn't look like a good solution
to me.
So, my question is where and how in hunchentoot I can raise an error so that
it would get propagated to the handler of the file upload request so that I
can show it to the user. In the request constructor (defmethod
initialize-instance ...) the body is wrapped into handler-case so any error
which occurs in it should be trapped by (error (cond) ...), right? For some
reason the error that I raise when the content-length is greater than some
number, this error gets trapped by the lisp debugger, not by (error (cond)
...). Anyway, time for me to go back study lisp manuals! :)

Andrew

On Sun, Sep 14, 2008 at 3:14 AM, Hans Hübner <hans at huebner.org> wrote:

> On Sun, Sep 14, 2008 at 00:55, Andrei Stebakov <lispercat at gmail.com>
> wrote:
> > I wonder what's the best way to handle the case when a user tries to
> upload
> > a very large file.
> > Basically we need to stop execution before it gets to the
> > parse-rfc2388-form-data and report the problem to the user.
> >[...]
> > Another thing, it's a dirty hack, what's the better way of doing this?
>
> I would fix the problem in RFC2388:READ-UNTIL-NEXT-BOUNDARY.  This
> function should read the data directly to the stream provided, and it
> should have a special variable (in the RFC2388 package) that can be
> set to limit the maximum number of bytes read.
>
> -Hans
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080914/6095d3c3/attachment.html>