Hi, guys.
I have the folowing question. Is there a posibility to check multipat/form-data request format before uploading files? I would like to write request handler which can check name and MIME of next file to be uploaded to have a possibility to abort request processing without wasting server resources while uploding huge files. The *upload-file-hook* doesn't help here because it cannot give a name and MIME of current file. What can you suggest me? Thanks in advance.
On Tue, Dec 1, 2009 at 21:56, Semion Prihodko semion.ababo@gmail.com wrote:
I have the folowing question. Is there a posibility to check multipat/form-data request format before uploading files? I would like to write request handler which can check name and MIME of next file to be uploaded to have a possibility to abort request processing without wasting server resources while uploding huge files.
Hunchentoot uses the rfc2388 library, which does not provide hooks beyond the MAKE-TMP-FILE-NAME function which is called when a file is being uploaded, to determine its filename. I have been wanting more customizability in the past, but we've never made that happen because we thought that we'd replace the rfc2388 library eventually. This has not happened, and it may not happen soon.
What exactly are you looking for, though? Do you want to decide whether to accept an upload by looking at the file name or the multipart header? Or do you want to inspect the uploaded data while uploading?
-Hans
Do you want to decide whether to accept an upload by looking at the file name or the multipart header? > yes.
Thank you for reply.
2009/12/2 Hans Hübner hans.huebner@gmail.com
On Tue, Dec 1, 2009 at 21:56, Semion Prihodko semion.ababo@gmail.com wrote:
I have the folowing question. Is there a posibility to check multipat/form-data request format before uploading files? I would like to write request handler which can check name and MIME of next file to be uploaded to have a possibility to abort request processing without
wasting
server resources while uploding huge files.
Hunchentoot uses the rfc2388 library, which does not provide hooks beyond the MAKE-TMP-FILE-NAME function which is called when a file is being uploaded, to determine its filename. I have been wanting more customizability in the past, but we've never made that happen because we thought that we'd replace the rfc2388 library eventually. This has not happened, and it may not happen soon.
What exactly are you looking for, though? Do you want to decide whether to accept an upload by looking at the file name or the multipart header? Or do you want to inspect the uploaded data while uploading?
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, Dec 2, 2009 at 10:47, Semion Prihodko semion.ababo@gmail.com wrote:
Do you want to decide whether to accept an upload by looking at the file name or the multipart header?
yes.
Assuming that "yes" means "I want to look at the file name": You can implement your own version of MAKE-TMP-FILE-NAME which checks the file name and generates an error if it does not suit. If you want to look at other MIME headers in the body part to decide whether the upload should proceed, you'll need to change the rfc2388 library. I'd implement a hook function that would be called from RFC2388:PARSE-MIME for each body part with the headers as argument.
-Hans
Thank you very much. I'll think about it.
2009/12/2 Hans Hübner hans.huebner@gmail.com
On Wed, Dec 2, 2009 at 10:47, Semion Prihodko semion.ababo@gmail.com wrote:
Do you want to decide whether to accept an upload by looking at the file
name or the
multipart header?
yes.
Assuming that "yes" means "I want to look at the file name": You can implement your own version of MAKE-TMP-FILE-NAME which checks the file name and generates an error if it does not suit. If you want to look at other MIME headers in the body part to decide whether the upload should proceed, you'll need to change the rfc2388 library. I'd implement a hook function that would be called from RFC2388:PARSE-MIME for each body part with the headers as argument.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Hans.
I've implemented a hook in rfc2388:parse-mime as you said me. Now I have the folowing little question. Can I be sure that EVERY request using POST method will initiate invocation of rfc2388:parse-mime? Thanks a lot.
2009/12/2 Semion Prihodko semion.ababo@gmail.com
Thank you very much. I'll think about it.
2009/12/2 Hans Hübner hans.huebner@gmail.com
On Wed, Dec 2, 2009 at 10:47, Semion Prihodko semion.ababo@gmail.com wrote:
Do you want to decide whether to accept an upload by looking at the
file name or the
multipart header?
yes.
Assuming that "yes" means "I want to look at the file name": You can implement your own version of MAKE-TMP-FILE-NAME which checks the file name and generates an error if it does not suit. If you want to look at other MIME headers in the body part to decide whether the upload should proceed, you'll need to change the rfc2388 library. I'd implement a hook function that would be called from RFC2388:PARSE-MIME for each body part with the headers as argument.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, Dec 8, 2009 at 09:54, Semion Prihodko semion.ababo@gmail.com wrote:
Can I be sure that EVERY request using POST method will initiate invocation of rfc2388:parse-mime?
I've not reviewed the code for this, but my gut feeling is that rfc2388:parse-mime is invoked whenever post-parameters is called for a request with a multipart body. If your handler does not do it (but instead, say, closes the connection), the body would not be parsed. If the body of the POST is not a multipart MIME entity, the parser also would not be called.
You'll need to inspect the hunchentoot code to be absolutely sure.
-Hans
I have a really stupid question but seems to me the answer cannot be easy gotten. If I define easy handler without immediate registering it to some URI how can I register and deregister it with some URI later? Thanks in advance.
You shouldn't re-use a subject header if you change the subject. Makes it hard to search the archive for this issue later.
On Wed, Dec 16, 2009 at 5:46 PM, Semion Prihodko semion.ababo@gmail.com wrote:
I have a really stupid question but seems to me the answer cannot be easy gotten. If I define easy handler without immediate registering it to some URI how can I register and deregister it with some URI later?
Modify the defining form and re-compile it. If an easy handler is defined, all existing easy handlers which have either the same name (EQ) or the same URI (EQUAL) are removed from the dispatcher's list first.
Edi.
but seems this is an ugly way... I would like to save reference to an easy handle and then arbitrary to enable it under some URI or disable. Does Hunchentoot support this kind of actions? Thanks.
2009/12/16 Edi Weitz edi@agharta.de
You shouldn't re-use a subject header if you change the subject. Makes it hard to search the archive for this issue later.
On Wed, Dec 16, 2009 at 5:46 PM, Semion Prihodko semion.ababo@gmail.com wrote:
I have a really stupid question but seems to me the answer cannot be easy gotten. If I define easy handler without immediate registering it to some URI how can I register and deregister it with some URI later?
Modify the defining form and re-compile it. If an easy handler is defined, all existing easy handlers which have either the same name (EQ) or the same URI (EQUAL) are removed from the dispatcher's list first.
Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, Dec 16, 2009 at 8:07 PM, Semion Prihodko semion.ababo@gmail.com wrote:
but seems this is an ugly way...
You're of course entitled to your own opinion... :)
I would like to save reference to an easy handle and then arbitrary to enable it under some URI or disable. Does Hunchentoot support this kind of actions?
Yes, it's explained in the documentation. You can use define-easy-handler without the URI parameter to simply define a named function. You can then use your own dispatch mechanism to associate this function with any URI(s) of your liking.
You can then use your own dispatch mechanism to associate this function with any URI(s) of your liking.
Please show me briefly how to do it. Thank you.
2009/12/16 Edi Weitz edi@agharta.de
On Wed, Dec 16, 2009 at 8:07 PM, Semion Prihodko semion.ababo@gmail.com wrote:
but seems this is an ugly way...
You're of course entitled to your own opinion... :)
I would like to save reference to an easy handle and then arbitrary to enable it under some URI or disable. Does Hunchentoot support this kind of actions?
Yes, it's explained in the documentation. You can use define-easy-handler without the URI parameter to simply define a named function. You can then use your own dispatch mechanism to associate this function with any URI(s) of your liking.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, Dec 16, 2009 at 8:29 PM, Semion Prihodko semion.ababo@gmail.com wrote:
Please show me briefly how to do it.
Request dispatch is described here:
http://weitz.de/hunchentoot/#request-dispatch
Write your own function which accepts a request object, looks at it, and then decides which (easy) handler to call. Look at the source code of the "define-xxx-dispatcher" functions to see examples for dispatch functions.
Thank you.
2009/12/16 Edi Weitz edi@agharta.de
On Wed, Dec 16, 2009 at 8:29 PM, Semion Prihodko semion.ababo@gmail.com wrote:
Please show me briefly how to do it.
Request dispatch is described here:
http://weitz.de/hunchentoot/#request-dispatch
Write your own function which accepts a request object, looks at it, and then decides which (easy) handler to call. Look at the source code of the "define-xxx-dispatcher" functions to see examples for dispatch functions.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Edi Weitz -
Hans Hübner -
Semion Prihodko