Hi
It's been discussed before (even prior Hunchentoot 1.0.0) that there has to be some way to allow the developer to calculate size of the file being uploaded and act upon that (maybe cancel the upload if the file is too big). Before I did it using a hack into parse-multipart-form-data function where I provided a callback to my own function which calculated the size of (header-in :content-length request) and if it was too big, aborted the request. I wonder if there is a better way to do it with the new architecture? Also if I put my own hacks into the ht code it would be difficult for me to update.
Thank you, Andrei
Andrei,
there are no specific hooks in the code that report the file size of uploaded files, but the situation has changed compared to 2008 in that we do no longer intend to replace the rfc2388 library in the foreseeable future. There are some pending changes regarding how uploaded files are handled which have not been merged because we're waiting for rfc2388 to be updated in Quicklisp. Maybe these changes help you, too: https://github.com/fighting-spirit/hunchentoot/commit/301db3d6f6291dd8690b09...
If you have any suggestions in form of a patch based on these changes that would help you get your problem solved, please let us know.
-Hans
On Wed, Jul 11, 2012 at 12:04 AM, Andrei Stebakov lispercat@gmail.com wrote:
Hi
It's been discussed before (even prior Hunchentoot 1.0.0) that there has to be some way to allow the developer to calculate size of the file being uploaded and act upon that (maybe cancel the upload if the file is too big). Before I did it using a hack into parse-multipart-form-data function where I provided a callback to my own function which calculated the size of (header-in :content-length request) and if it was too big, aborted the request. I wonder if there is a better way to do it with the new architecture? Also if I put my own hacks into the ht code it would be difficult for me to update.
Thank you, Andrei
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Quoth Hans Hübner hans.huebner@gmail.com:
[...] There are some pending changes regarding how uploaded files are handled which have not been merged because we're waiting for rfc2388 to be updated in Quicklisp.
Has this happened?
I have Quicklisp version 2012-12-23 installled and it ships version 1.5 of rfc2388.
Also, rfc2388's source directory has the name rfc2388-20121013-git/. Is this a reason for hope?
Maybe these changes help you, too: https://github.com/fighting-spirit/hunchentoot/commit/301db3d6f6291dd8690b09...
It looks like *UPLOAD-FILENAME-GENERATOR* does what I need.
Alternatively, how about adding a tmp-directory slot to the ACCEPTOR class and then replacing all references to *TMP-DIRECTORY* with:
(or (tmp-directory request) *TMP-DIRECTORY*)
All I really need is per-acceptor control over the directory into which temporary files are written (in my case, the file name is unimportant) so this would also serve my purposes.
Seb
Sebastian,
I have nagged jdz about the pending changes to rfc2388, as they have still not made it into Quicklisp. They are in the parse-mime-change branch of git://github.com/jdz/rfc2388.git, if you're interested.
I'm not sure about the general usefulness of a per-acceptor temporary directory. Can't you subclass Hunchentoot's acceptor class and then bind *TMP-DIRECTORY* in a HANDLE-REQUEST :AROUND method?
-Hans
On Tue, Jan 15, 2013 at 11:24 PM, Sebastian Tennant sebyte@smolny.plus.comwrote:
Quoth Hans Hübner hans.huebner@gmail.com:
[...] There are some pending changes regarding how uploaded files are
handled
which have not been merged because we're waiting for rfc2388 to be
updated in
Quicklisp.
Has this happened?
I have Quicklisp version 2012-12-23 installled and it ships version 1.5 of rfc2388.
Also, rfc2388's source directory has the name rfc2388-20121013-git/. Is this a reason for hope?
Maybe these changes help you, too:
https://github.com/fighting-spirit/hunchentoot/commit/301db3d6f6291dd8690b09...
It looks like *UPLOAD-FILENAME-GENERATOR* does what I need.
Alternatively, how about adding a tmp-directory slot to the ACCEPTOR class and then replacing all references to *TMP-DIRECTORY* with:
(or (tmp-directory request) *TMP-DIRECTORY*)
All I really need is per-acceptor control over the directory into which temporary files are written (in my case, the file name is unimportant) so this would also serve my purposes.
Seb
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Hans,
Quoth Hans Hübner hans.huebner@gmail.com:
I have nagged jdz about the pending changes to rfc2388, as they have still not made it into Quicklisp. They are in the parse-mime-change branch of git://github.com/jdz /rfc2388.git, if you're interested.
I'm not sure about the general usefulness of a per-acceptor temporary directory. Can't you subclass Hunchentoot's acceptor class and then bind *TMP-DIRECTORY* in a HANDLE-REQUEST :AROUND method?
Thanks for the tip. Will I ever start thinking more ooply and less procly, I wonder.
I've gone with an :AROUND method on POST-PARAMETERS because I want to control the temporary destination directory of file uploads only.
Can you forsee a problem with this?
Seb
On Wed, Jan 16, 2013 at 11:20 AM, Sebastian Tennant sebyte@smolny.plus.comwrote:
I've gone with an :AROUND method on POST-PARAMETERS because I want to control the temporary destination directory of file uploads only.
Can you forsee a problem with this?
No, that sounds good. If you encounter any problems with the approach, let us know.
-Hans
Whoops!
(or (tmp-directory *acceptor*) *tmp-directory*)
is what I meant to say.
Seb
-
Andrei Stebakov -
Hans Hübner -
Sebastian Tennant