From semion.ababo at gmail.com Tue Dec 1 20:56:57 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Tue, 1 Dec 2009 22:56:57 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Dec 2 07:43:26 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 2 Dec 2009 08:43:26 +0100 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: On Tue, Dec 1, 2009 at 21:56, Semion Prihodko 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 From semion.ababo at gmail.com Wed Dec 2 09:47:38 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 2 Dec 2009 11:47:38 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: 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 > On Tue, Dec 1, 2009 at 21:56, Semion Prihodko > 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Dec 2 10:05:45 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 2 Dec 2009 11:05:45 +0100 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: On Wed, Dec 2, 2009 at 10:47, Semion Prihodko 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 From semion.ababo at gmail.com Wed Dec 2 10:36:03 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 2 Dec 2009 12:36:03 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: Thank you very much. I'll think about it. 2009/12/2 Hans H?bner > On Wed, Dec 2, 2009 at 10:47, Semion Prihodko > 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mackram at gmail.com Wed Dec 2 22:04:04 2009 From: mackram at gmail.com (Mackram Raydan) Date: Thu, 3 Dec 2009 00:04:04 +0200 Subject: [hunchentoot-devel] Getting multiple post parameters with same name Message-ID: <37654d130912021404v300ccecaq9e25fd5e97fc71f@mail.gmail.com> Hey Everyone, So I was wondering if there is any way for us to get multiple post parameters with the same name from a Hunchentoot request without incurring a performance hit. Appreciate any help that could be offered over this. Thank you all in advance, Regards, Mackram Raydan Company: www.imagimate.com Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Dec 2 22:20:38 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 2 Dec 2009 23:20:38 +0100 Subject: [hunchentoot-devel] Getting multiple post parameters with same name In-Reply-To: <37654d130912021404v300ccecaq9e25fd5e97fc71f@mail.gmail.com> References: <37654d130912021404v300ccecaq9e25fd5e97fc71f@mail.gmail.com> Message-ID: Mackram, how does the POST-PARAMETERS method not meet your requirements? What exactly do you mean by "without incurring a performance hit"? -Hans On Wed, Dec 2, 2009 at 23:04, Mackram Raydan wrote: > Hey Everyone, > > So I was wondering if there is any way for us to get multiple post > parameters with the same name from a Hunchentoot request without incurring a > performance hit. Appreciate any help that could be offered over this. > > Thank you all in advance, > > Regards, > > Mackram Raydan > > Company: www.imagimate.com > Website: www.trailoflight.net > > "An invasion of armies can be resisted, but not an idea whose time has > come." Victor Hugo > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From mackram at gmail.com Thu Dec 3 16:14:26 2009 From: mackram at gmail.com (Mackram Raydan) Date: Thu, 3 Dec 2009 18:14:26 +0200 Subject: [hunchentoot-devel] Getting multiple post parameters with same name In-Reply-To: References: <37654d130912021404v300ccecaq9e25fd5e97fc71f@mail.gmail.com> Message-ID: <37654d130912030814y380c478awa0f2e2d45959049f@mail.gmail.com> Hey Hans the documentation states that post-parameters will return alist and according to my knowledge (which I admit is basic) processing alist for search is not very recommended please correct me if I am wrong Thanks Mackram On Dec 3, 2009 12:22 AM, "Hans H?bner" wrote: Mackram, how does the POST-PARAMETERS method not meet your requirements? What exactly do you mean by "without incurring a performance hit"? -Hans On Wed, Dec 2, 2009 at 23:04, Mackram Raydan wrote: > Hey Everyone, > > So I wa... > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > _______________________________________________ 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: From hans.huebner at gmail.com Thu Dec 3 16:26:45 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 3 Dec 2009 17:26:45 +0100 Subject: [hunchentoot-devel] Getting multiple post parameters with same name In-Reply-To: <37654d130912030814y380c478awa0f2e2d45959049f@mail.gmail.com> References: <37654d130912021404v300ccecaq9e25fd5e97fc71f@mail.gmail.com> <37654d130912030814y380c478awa0f2e2d45959049f@mail.gmail.com> Message-ID: On Thu, Dec 3, 2009 at 17:14, Mackram Raydan wrote: > Hey Hans the documentation states that post-parameters will return alist and > according to my knowledge (which I admit is basic) processing alist for > search is not very recommended please correct me if I am wrong Hunchentoot uses an alist for the headers internally, so you may as well do it externally. Using alists for large amounts of data can be unacceptably slow as access time is linear. For (post) parameters, this is not a problem as the number of parameters is slow and a "better" data structure may very well be slower for the small number of items that typically constitute a request parameter list. Before being scared about certain data structures in the future, make some measurements and consider the use case. -Hans From semion.ababo at gmail.com Tue Dec 8 08:54:07 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Tue, 8 Dec 2009 10:54:07 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: 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 > Thank you very much. I'll think about it. > > 2009/12/2 Hans H?bner > >> On Wed, Dec 2, 2009 at 10:47, Semion Prihodko >> 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 at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Tue Dec 8 09:05:19 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 8 Dec 2009 10:05:19 +0100 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: On Tue, Dec 8, 2009 at 09:54, Semion Prihodko 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 From vsedach at gmail.com Sat Dec 12 06:41:42 2009 From: vsedach at gmail.com (Vladimir Sedach) Date: Sat, 12 Dec 2009 01:41:42 -0500 Subject: [hunchentoot-devel] Debugging acceptor in SVN repo doesn't work with SLIME Message-ID: When I try to use it with SLIME on SBCL, it invokes the debugger in *inferior-lisp* instead of SWANK. I tried to figure it out before but couldn't, but what just popped into my head is that this could be due to different bindings for dynamic variables in Hunchentoot threads vs. the SWANK repl thread. On another note, I don't like the debugging-acceptor code. What was wrong with http://paste.lisp.org/display/81046? That was much more straightforward. Vladimir From edi at agharta.de Sat Dec 12 10:25:14 2009 From: edi at agharta.de (Edi Weitz) Date: Sat, 12 Dec 2009 11:25:14 +0100 Subject: [hunchentoot-devel] Debugging acceptor in SVN repo doesn't work with SLIME In-Reply-To: References: Message-ID: On Sat, Dec 12, 2009 at 7:41 AM, Vladimir Sedach wrote: > When I try to use it with SLIME on SBCL, it invokes the debugger in > *inferior-lisp* instead of SWANK. I tried to figure it out before but > couldn't, but what just popped into my head is that this could be due > to different bindings for dynamic variables in Hunchentoot threads vs. > the SWANK repl thread. Can't comment on this one as I haven't used SLIME with the latest Hunchentoot yet. > On another note, I don't like the debugging-acceptor code. What was > wrong with http://paste.lisp.org/display/81046? That was much more > straightforward. See the recent discussions about the debugging-acceptor on this list. There will be some changes before there's a release. Cheers, Edi. From zaries at global.co.za Wed Dec 16 11:20:16 2009 From: zaries at global.co.za (Phil Marneweck) Date: Wed, 16 Dec 2009 13:20:16 +0200 Subject: [hunchentoot-devel] Hunchentoot Recursive Function Message-ID: <1260962416.2320.47.camel@scatha> This is most likely a problem with my understanding of lisp and not hunchnetoot. Why does the following function only out put "Recursive count- 0" to the hunchentoot page? (defun recursive-test (count) (with-html-output-to-string (*standard-output*) (if (< count 10) (recursive-test (+ count 1))) (str (format nil "Recursive count- ~A" count)))) (define-easy-handler (test-recursive :uri "/test.html" () (with-html-output-to-string (*standard-output*) (str (recursive-test 0)))) From zaries at global.co.za Wed Dec 16 12:03:30 2009 From: zaries at global.co.za (Phil Marneweck) Date: Wed, 16 Dec 2009 14:03:30 +0200 Subject: [hunchentoot-devel] Hunchentoot Recursive Function In-Reply-To: <1260962416.2320.47.camel@scatha> References: <1260962416.2320.47.camel@scatha> Message-ID: <1260965010.2320.50.camel@scatha> Ok I got some help in #lisp I now have the following: (defun recursive-test (count) (with-html-output (*standard-output*) (if (< count 10) (recursive-test (+ count 1))) (str (format nil "Recursive count- ~A" count)))) (define-easy-handler (test-recursive :uri "/test.html" :default-request-type :both) () (with-html-output-to-string (*standard-output*) (recursive-test 0))) Which gives me: Recursive count- 10Recursive count- 9Recursive count- 8Recursive count- 7Recursive count- 6Recursive count- 5Recursive count- 4Recursive count- 3Recursive count- 2Recursive count- 1Recursive count- 0Recursive count- 0 Why do I get 2 Recursive count- 0? Is this hunchentoot or am I not understanding recursion in lisp? On Wed, 2009-12-16 at 13:20 +0200, Phil Marneweck wrote: > This is most likely a problem with my understanding of lisp and not > hunchnetoot. > > Why does the following function only out put "Recursive count- 0" to the > hunchentoot page? > > (defun recursive-test (count) > (with-html-output-to-string (*standard-output*) > (if (< count 10) > (recursive-test (+ count 1))) > (str (format nil "Recursive count- ~A" count)))) > > (define-easy-handler (test-recursive :uri "/test.html" () > (with-html-output-to-string (*standard-output*) > (str (recursive-test 0)))) > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From zaries at global.co.za Wed Dec 16 12:06:06 2009 From: zaries at global.co.za (Phil Marneweck) Date: Wed, 16 Dec 2009 14:06:06 +0200 Subject: [hunchentoot-devel] When to use with-html-output and when to use with-html-output-to-string Message-ID: <1260965166.2320.52.camel@scatha> When should one use with-html-output and when should one use with-html-output-to-string? From zaries at global.co.za Wed Dec 16 12:18:10 2009 From: zaries at global.co.za (Phil Marneweck) Date: Wed, 16 Dec 2009 14:18:10 +0200 Subject: [hunchentoot-devel] Hunchentoot Recursive Function In-Reply-To: <1260965010.2320.50.camel@scatha> References: <1260962416.2320.47.camel@scatha> <1260965010.2320.50.camel@scatha> Message-ID: <1260965890.2320.55.camel@scatha> Just a correction this code is the code that actually created the Recursive count- 0 and not the previous code...the previous code is actualy the code that gives the correct output (defun recursive-test (count) (with-html-output (*standard-output*) (if (< count 10) (recursive-test (+ count 1))) (str (format nil "Recursive count- ~A" count)))) (define-easy-handler (test-recursive :uri "/test.html" :default-request-type :both) () (with-html-output-to-string (*standard-output*) (str (recursive-test 0)))) On Wed, 2009-12-16 at 14:03 +0200, Phil Marneweck wrote: > Ok I got some help in #lisp > > I now have the following: > > (defun recursive-test (count) > (with-html-output (*standard-output*) > (if (< count 10) > (recursive-test (+ count 1))) > > (str (format nil "Recursive count- ~A" count)))) > > (define-easy-handler (test-recursive :uri > "/test.html" :default-request-type :both) () > (with-html-output-to-string (*standard-output*) > (recursive-test 0))) > > Which gives me: > > Recursive count- 10Recursive count- 9Recursive count- 8Recursive count- > 7Recursive count- 6Recursive count- 5Recursive count- 4Recursive count- > 3Recursive count- 2Recursive count- 1Recursive count- 0Recursive count- > 0 > > Why do I get 2 Recursive count- 0? > > Is this hunchentoot or am I not understanding recursion in lisp? > > > On Wed, 2009-12-16 at 13:20 +0200, Phil Marneweck wrote: > > This is most likely a problem with my understanding of lisp and not > > hunchnetoot. > > > > Why does the following function only out put "Recursive count- 0" to the > > hunchentoot page? > > > > (defun recursive-test (count) > > (with-html-output-to-string (*standard-output*) > > (if (< count 10) > > (recursive-test (+ count 1))) > > (str (format nil "Recursive count- ~A" count)))) > > > > (define-easy-handler (test-recursive :uri "/test.html" () > > (with-html-output-to-string (*standard-output*) > > (str (recursive-test 0)))) > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From cavandusen at gmail.com Wed Dec 16 11:50:54 2009 From: cavandusen at gmail.com (Chris Van Dusen) Date: Wed, 16 Dec 2009 05:50:54 -0600 Subject: [hunchentoot-devel] Hunchentoot Recursive Function In-Reply-To: <1260962416.2320.47.camel@scatha> References: <1260962416.2320.47.camel@scatha> Message-ID: <5EB15DEE-0255-4C38-9151-61844E016E5E@gmail.com> On Dec 16, 2009, at 5:20 AM, Phil Marneweck wrote: > This is most likely a problem with my understanding of lisp and not > hunchnetoot. > > Why does the following function only out put "Recursive count- 0" to the > hunchentoot page? > > (defun recursive-test (count) > (with-html-output-to-string (*standard-output*) > (if (< count 10) > (recursive-test (+ count 1))) > (str (format nil "Recursive count- ~A" count)))) > > (define-easy-handler (test-recursive :uri "/test.html" () > (with-html-output-to-string (*standard-output*) > (str (recursive-test 0)))) > It has to do with format being passed nil: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_format.html#format Chris. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From mail at chaitanyagupta.com Wed Dec 16 12:04:50 2009 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Wed, 16 Dec 2009 17:34:50 +0530 Subject: [hunchentoot-devel] Hunchentoot Recursive Function In-Reply-To: <1260962416.2320.47.camel@scatha> References: <1260962416.2320.47.camel@scatha> Message-ID: <4B28CCE2.6060309@chaitanyagupta.com> Phil Marneweck wrote: > This is most likely a problem with my understanding of lisp and not > hunchnetoot. > > Why does the following function only out put "Recursive count- 0" to the > hunchentoot page? > This might be more of an issue with your understanding of CL-WHO rather than Lisp ;) (defun recursive-test (count) (with-html-output (*standard-output*) (if (< count 10) (recursive-test (+ count 1))) (str (format nil "Recursive count- ~A~%" count)))) Note that I am using WITH-HTML-OUTPUT instead of WITH-HTML-OUTPUT-TO-STRING. This way, output by all recursive calls would go to *standard-output* which is then be handled by TEST-RECURSIVE. (define-easy-handler (test-recursive :uri "/test.html") () (with-html-output-to-string (*standard-output*) (recursive-test 0))) We don't need the (STR ...) around (RECURSIVE-TEST 0) since we are not interested in the return value. Also, you don't necessarily need to use WITH-HTML-OUTPUT-TO-STRING here -- even WITH-OUTPUT-TO-STRING would work. Chaitanya > (defun recursive-test (count) > (with-html-output-to-string (*standard-output*) > (if (< count 10) > (recursive-test (+ count 1))) > (str (format nil "Recursive count- ~A" count)))) > > (define-easy-handler (test-recursive :uri "/test.html" () > (with-html-output-to-string (*standard-output*) > (str (recursive-test 0)))) > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- http://chaitanyagupta.com/blog/ From zaries at global.co.za Wed Dec 16 13:19:16 2009 From: zaries at global.co.za (Phil Marneweck) Date: Wed, 16 Dec 2009 15:19:16 +0200 Subject: [hunchentoot-devel] Hunchentoot Recursive Function In-Reply-To: <4B28CCE2.6060309@chaitanyagupta.com> References: <1260962416.2320.47.camel@scatha> <4B28CCE2.6060309@chaitanyagupta.com> Message-ID: <1260969556.2320.60.camel@scatha> Thanx I got the same answer on #lisp For some reason I only received this mail an hour after you actually sent it, thus my latter posts...appologize to the group as a whole for that. I was not ignoring answers on the mailing list I just did not get them until to late. On Wed, 2009-12-16 at 17:34 +0530, Chaitanya Gupta wrote: > Phil Marneweck wrote: > > This is most likely a problem with my understanding of lisp and not > > hunchnetoot. > > > > Why does the following function only out put "Recursive count- 0" to the > > hunchentoot page? > > > > This might be more of an issue with your understanding of CL-WHO rather > than Lisp ;) > > (defun recursive-test (count) > (with-html-output (*standard-output*) > (if (< count 10) > (recursive-test (+ count 1))) > (str (format nil "Recursive count- ~A~%" count)))) > > Note that I am using WITH-HTML-OUTPUT instead of > WITH-HTML-OUTPUT-TO-STRING. This way, output by all recursive calls > would go to *standard-output* which is then be handled by TEST-RECURSIVE. > > (define-easy-handler (test-recursive :uri "/test.html") () > (with-html-output-to-string (*standard-output*) > (recursive-test 0))) > > We don't need the (STR ...) around (RECURSIVE-TEST 0) since we are not > interested in the return value. Also, you don't necessarily need to use > WITH-HTML-OUTPUT-TO-STRING here -- even WITH-OUTPUT-TO-STRING would work. > > Chaitanya > > > (defun recursive-test (count) > > (with-html-output-to-string (*standard-output*) > > (if (< count 10) > > (recursive-test (+ count 1))) > > (str (format nil "Recursive count- ~A" count)))) > > > > (define-easy-handler (test-recursive :uri "/test.html" () > > (with-html-output-to-string (*standard-output*) > > (str (recursive-test 0)))) > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > From oruppert at googlemail.com Wed Dec 16 12:22:18 2009 From: oruppert at googlemail.com (Olaf Ruppert) Date: Wed, 16 Dec 2009 13:22:18 +0100 Subject: [hunchentoot-devel] When to use with-html-output and when to use with-html-output-to-string In-Reply-To: <1260965166.2320.52.camel@scatha> References: <1260965166.2320.52.camel@scatha> Message-ID: <62d94dee0912160422j6139b90aq28ef9ff8fc9d4eea@mail.gmail.com> http://weitz.de/cl-who/#with-html-output-to-string On Wed, Dec 16, 2009 at 1:06 PM, Phil Marneweck wrote: > When should one use with-html-output and when should one use > with-html-output-to-string? > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From zaries at global.co.za Wed Dec 16 13:44:28 2009 From: zaries at global.co.za (Phil Marneweck) Date: Wed, 16 Dec 2009 15:44:28 +0200 Subject: [hunchentoot-devel] When to use with-html-output and when to use with-html-output-to-string In-Reply-To: <62d94dee0912160422j6139b90aq28ef9ff8fc9d4eea@mail.gmail.com> References: <1260965166.2320.52.camel@scatha> <62d94dee0912160422j6139b90aq28ef9ff8fc9d4eea@mail.gmail.com> Message-ID: <1260971068.2320.74.camel@scatha> Thanx for the link, I have looked at that a couple of times but until now I have not really put my mind to the issue. What I am actually trying to ask is whether the follwoing statement would be true: In general one should use with-html-output and reserve with-html-output-to-string for those times that you want to intentionally "delay" the actual rendering of the html generated untill needed. In other words should one On Wed, 2009-12-16 at 13:22 +0100, Olaf Ruppert wrote: > http://weitz.de/cl-who/#with-html-output-to-string > > > > On Wed, Dec 16, 2009 at 1:06 PM, Phil Marneweck wrote: > > When should one use with-html-output and when should one use > > with-html-output-to-string? > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Wed Dec 16 14:13:36 2009 From: edi at agharta.de (Edi Weitz) Date: Wed, 16 Dec 2009 15:13:36 +0100 Subject: [hunchentoot-devel] When to use with-html-output and when to use with-html-output-to-string In-Reply-To: <1260971068.2320.74.camel@scatha> References: <1260965166.2320.52.camel@scatha> <62d94dee0912160422j6139b90aq28ef9ff8fc9d4eea@mail.gmail.com> <1260971068.2320.74.camel@scatha> Message-ID: On Wed, Dec 16, 2009 at 2:44 PM, Phil Marneweck wrote: > Thanx for the link, I have looked at that a couple of times but until > now I have not really put my mind to the issue. > > What I am actually trying to ask is whether the follwoing statement > would be true: > > In general one should use with-html-output and reserve > with-html-output-to-string for those times that you want to > intentionally "delay" the actual rendering of the html generated untill > needed. Both macros do essentially the same thing, they both write to a stream. W-H-O writes to a stream you specify, W-H-O-T-S writes to a string stream and returns the string it generated. Or in other words, W-H-O-T-S is just a convenience wrapper around W-H-O. See the source code for its definition. As was already said, this should really be discussed on the CL-WHO mailing list. Cheers, Edi. From semion.ababo at gmail.com Wed Dec 16 16:46:13 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 16 Dec 2009 18:46:13 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Dec 16 18:34:56 2009 From: edi at agharta.de (Edi Weitz) Date: Wed, 16 Dec 2009 19:34:56 +0100 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: 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 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. From semion.ababo at gmail.com Wed Dec 16 19:07:44 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 16 Dec 2009 21:07:44 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: 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 > 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 > 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Dec 16 19:15:41 2009 From: edi at agharta.de (Edi Weitz) Date: Wed, 16 Dec 2009 20:15:41 +0100 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: On Wed, Dec 16, 2009 at 8:07 PM, Semion Prihodko 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. From semion.ababo at gmail.com Wed Dec 16 19:29:36 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 16 Dec 2009 21:29:36 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: > 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 > On Wed, Dec 16, 2009 at 8:07 PM, Semion Prihodko > 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Dec 16 19:51:39 2009 From: edi at agharta.de (Edi Weitz) Date: Wed, 16 Dec 2009 20:51:39 +0100 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: On Wed, Dec 16, 2009 at 8:29 PM, Semion Prihodko 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. From semion.ababo at gmail.com Wed Dec 16 20:40:30 2009 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 16 Dec 2009 22:40:30 +0200 Subject: [hunchentoot-devel] Controlling file uploads with hunchentoot In-Reply-To: References: Message-ID: Thank you. 2009/12/16 Edi Weitz > On Wed, Dec 16, 2009 at 8:29 PM, Semion Prihodko > 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth at tewebs.com Sat Dec 19 17:56:57 2009 From: seth at tewebs.com (Seth) Date: Sat, 19 Dec 2009 11:56:57 -0600 Subject: [hunchentoot-devel] Hunchentoot on Clozure windows x86 Message-ID: <200912191756.nBJHuvtV017691@smtp-webmail.ivenue.com> Im trying to get hunchentoot to run on windows vista. Everything compiles successfully and i downloaded opensll and installed dlls into the system directory. However, when i type the following into emacs (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name) (setf (hunchentoot:content-type*) "text/plain") (format nil "Hey~@[ ~A~]!" name)) and go to http://127.0.0.1:4242/yo, i see a blank page. In fact, i can go to /anything and still see a blank page, even though it should (?) produce an error since that page wasn't defined. So what should i do to start debugging this? Thanks! ---- Msg sent via WebMail From edi at agharta.de Sat Dec 19 19:52:08 2009 From: edi at agharta.de (Edi Weitz) Date: Sat, 19 Dec 2009 20:52:08 +0100 Subject: [hunchentoot-devel] Hunchentoot on Clozure windows x86 In-Reply-To: <200912191756.nBJHuvtV017691@smtp-webmail.ivenue.com> References: <200912191756.nBJHuvtV017691@smtp-webmail.ivenue.com> Message-ID: On Sat, Dec 19, 2009 at 6:56 PM, Seth wrote: > So what should i do to start debugging this? Some ideas: 1. Check if anything is actually listening on port 4242. 2. Set *break-on-signals* to t and then send a request from your browser and see what happens. Or if anything happens at all. Cheers, Edi. From edi at agharta.de Tue Dec 22 21:08:20 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 22 Dec 2009 22:08:20 +0100 Subject: [hunchentoot-devel] updated version In-Reply-To: <8fbe874a0910270652k4d22fb90wa6884253270be79c@mail.gmail.com> References: <1256609821.12526.5.camel@Pandora> <1256644671.12526.10.camel@Pandora> <8fbe874a0910270652k4d22fb90wa6884253270be79c@mail.gmail.com> Message-ID: On Tue, Oct 27, 2009 at 2:52 PM, Bill St. Clair wrote: > For me, STOP returns, but the listener process doesn't exit. Sorry for the late reply, but so far I didn't have the time to test the new version on Lisps other than LispWorks. I just tried the current SVN version with SBCL 1.0.32 on Linux x86 and it works for me - STOP returns and the listener process exits. That was with usocket 0.4.1 in case that matters. (Should I have used the repository version instead?) From edi at agharta.de Tue Dec 22 22:05:07 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 22 Dec 2009 23:05:07 +0100 Subject: [hunchentoot-devel] Specializing process-request In-Reply-To: <82fx82x0lr.fsf@netfonds.no> References: <82vdgzvvvl.fsf@netfonds.no> <82k4xex5r6.fsf@netfonds.no> <82fx82x0lr.fsf@netfonds.no> Message-ID: On Wed, Nov 25, 2009 at 1:14 PM, Frode V. Fjeld wrote: > *within-request-p* [why not just (not (null *request*))?] Because *request* is unbound outside of requests... :) But I've removed *with-request-p* in the repository now. Thanks, Edi. From edi at agharta.de Tue Dec 22 22:22:26 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 22 Dec 2009 23:22:26 +0100 Subject: [hunchentoot-devel] Specializing process-request In-Reply-To: References: <82vdgzvvvl.fsf@netfonds.no> <82k4xex5r6.fsf@netfonds.no> <82fx82x0lr.fsf@netfonds.no> Message-ID: On Mon, Nov 30, 2009 at 2:16 PM, Hans H?bner wrote: > I have committed that patch to the Subversion repository. Sorry, I'm very slowly catching up with Hunchentoot work. I've revoked this patch for now because the documentation was incorrect in several places (it said that process-request is called anew for each request, that process-request calls the acceptor's request dispatcher, and so on). Also, I think that this addition is not really necessary as you can bind any special variables in your own request dispatcher if you want, or am I missing something? Thanks, Edi. From edi at agharta.de Sun Dec 27 22:11:14 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 27 Dec 2009 23:11:14 +0100 Subject: [hunchentoot-devel] Backtrace display + idea for "representations" In-Reply-To: <1BFA29A5-4421-42A4-894E-34D9319AAF74@crispylogics.com> References: <91d4af8bc5cf8fc977275d3ec1d6c800.squirrel@mail.stardawn.org> <1BFA29A5-4421-42A4-894E-34D9319AAF74@crispylogics.com> Message-ID: Jochen, this is another email I unfortunately haven't replied to yet. Sorry again. I can kind of understand that the concept of representation classes is tempting in terms of a clean architecture, but right now I fail to see what it would give us in practice. Could you provide an example of how one would extend this mechanism to do something that can't be done right now (or only in a "dirty" way)? Thanks, Edi. On Thu, Sep 3, 2009 at 9:30 AM, Jochen Schmidt wrote: > Hans, > > As outlined before - *break-on-signals* is not a good solution. Not > all conditions are errors or useful break points. If we really have to > fallback to ANSI CL means for that purpose, wrapping a handler-bind > like in Andreas' Solution is better - I use something similar in my > code (Actually I do handle all conditions in my handlers now, because > I didn't get hunchentoots error handling to do what I wanted). > Documentation may help, or not; some clear protocols would be > perfect :-) > > Hunchentoot evolved really well towards 1.0. I really appreciate the > extensibility one now gets through some clearer protocols (task- > managers, request-/reply-class a. s. o.). I still see some open > problems though. Hunchentoot completely misses the concept of a > "representation" - instead it uses either strings or octet-streams > directly in an ad hoc way. Perhaps it would be a good idea to abstract > this underlying representations using a small set of extensible > representation classes? Something like: > > representation > ? ? ? | > ? ? / | \ > ? ? | | ?string-representation > ? ? | | > ? ? | file-representation > ? ? | > stream-representation > > A handler would then not either return a string or write itself into > the stream one gets from send-headers, but it would generate (or > select) a representation object and hunchentoot handles this > automatically. > > ciao, > Jochen > > -- > Jochen Schmidt > > Am 03.09.2009 um 08:45 schrieb Hans H?bner : > >> We have removed the backtrace support from Hunchentoot because we >> wanted to get rid of all non-essential system dependencies. ?For >> interactive debugging, the *BREAK-ON-SIGNALS* special variable can >> (should) be used, it can do what the presented acceptor subclass can >> do. ?If you really need backtraces in your log files, the >> trivial-backtrace [2] library may be useful. >> >> It would be useful to have a section on debugging in the manual. >> >> -Hans >> >> [1] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/var_stbreak-on-signalsst.html >> [2] http://common-lisp.net/project/trivial-backtrace/ >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From edi at agharta.de Sun Dec 27 23:08:09 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 28 Dec 2009 00:08:09 +0100 Subject: [hunchentoot-devel] Imminent release Message-ID: Hi, I've made a couple of changes tonight (notably adding *catch-errors-p* and *log-lisp-backtraces-p* back in and exposing a new function handle-request along the lines of Frode's suggestions). I'm planning to make a new release in the next days based on what's in the BKNR repository right now. I've only tested on LispWorks so far (and I have no plans to test on other Lisps for now). If you find any obvious errors, please let me know. Also, if you've provided code in the last months which made it into the upcoming release but aren't mentioned in the changelog, let me know as well. My apologies for having been pretty passive with Hunchentoot in the last months, but there were (and still are) too many other things to do. Thanks, Edi.