From jeffrey at cunningham.net Fri Dec 1 01:43:01 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Thu, 30 Nov 2006 17:43:01 -0800 Subject: [hunchentoot-devel] Progress with SSL In-Reply-To: <20061126025254.GA27726@achilles.olympus.net> References: <20061126025254.GA27726@achilles.olympus.net> Message-ID: <20061201014301.GA6775@achilles.olympus.net> Edi was right - when I compiled my SSL testcase using SBCL it worked. So there is a problem with CMUCL. I was using 19d rev2 (x86 binary loaded from one of their mirrors). --Jeff From edi at agharta.de Fri Dec 1 07:49:40 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 01 Dec 2006 08:49:40 +0100 Subject: [hunchentoot-devel] Progress with SSL In-Reply-To: <20061201014301.GA6775@achilles.olympus.net> (Jeffrey Cunningham's message of "Thu, 30 Nov 2006 17:43:01 -0800") References: <20061126025254.GA27726@achilles.olympus.net> <20061201014301.GA6775@achilles.olympus.net> Message-ID: On Thu, 30 Nov 2006 17:43:01 -0800, Jeffrey Cunningham wrote: > Edi was right - when I compiled my SSL testcase using SBCL it > worked. So there is a problem with CMUCL. I was using 19d rev2 (x86 > binary loaded from one of their mirrors). It might be useful to report that to the CL+SSL maintainer. He'd probably prefer an isolated test case, but it's better than nothing. Thanks for the info, Edi. From edi at agharta.de Fri Dec 1 08:27:30 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 01 Dec 2006 09:27:30 +0100 Subject: [hunchentoot-devel] New release 0.4.11 (Was: Expired sessions) In-Reply-To: <200611301932.45944.ndj@hivsa.com> (Nico de Jager's message of "Thu, 30 Nov 2006 19:32:45 +0200") References: <200611301753.32186.ndj@hivsa.com> <200611301914.21294.ndj@hivsa.com> <200611301932.45944.ndj@hivsa.com> Message-ID: On Thu, 30 Nov 2006 19:32:45 +0200, Nico de Jager wrote: > If you don't export *SESSION-GC-FREQUENCY* and/or SESSION-GC, maybe > a short note about this can be added to your already excellent > documentation? I've exported and documented the relevant symbols in this new release. Thanks for the suggestion, Edi. From ndj at hivsa.com Fri Dec 1 10:30:03 2006 From: ndj at hivsa.com (Nico de Jager) Date: Fri, 1 Dec 2006 12:30:03 +0200 Subject: [hunchentoot-devel] Re: New release 0.4.11 (Was: Expired sessions) In-Reply-To: References: <200611301753.32186.ndj@hivsa.com> <200611301932.45944.ndj@hivsa.com> Message-ID: <200612011230.03423.ndj@hivsa.com> On Friday 01 December 2006 10:27, Edi Weitz wrote: > On Thu, 30 Nov 2006 19:32:45 +0200, Nico de Jager wrote: > > If you don't export *SESSION-GC-FREQUENCY* and/or SESSION-GC, maybe > > a short note about this can be added to your already excellent > > documentation? > > I've exported and documented the relevant symbols in this new release. I see there is a new predicate as well, SESSION-TOO-OLD-P. This can be helpfull when traversing session. Great work as usuall. Best wishes. Nico From jeffrey at cunningham.net Sat Dec 2 19:33:43 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Sat, 2 Dec 2006 11:33:43 -0800 Subject: [hunchentoot-devel] loop over session values? Message-ID: <20061202193343.GB9526@achilles.olympus.net> Is there a way to loop over all the session-values that have been set in a session? Something like DO-SESSION-VALUES? The only way I can think to do it now involves exploiting the structure of *session* object, which is supposed to be considered opaque. --Jeff From edi at agharta.de Sat Dec 2 23:04:28 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 03 Dec 2006 00:04:28 +0100 Subject: [hunchentoot-devel] loop over session values? In-Reply-To: <20061202193343.GB9526@achilles.olympus.net> (Jeffrey Cunningham's message of "Sat, 2 Dec 2006 11:33:43 -0800") References: <20061202193343.GB9526@achilles.olympus.net> Message-ID: On Sat, 2 Dec 2006 11:33:43 -0800, Jeffrey Cunningham wrote: > Is there a way to loop over all the session-values that have been > set in a session? Something like DO-SESSION-VALUES? > > The only way I can think to do it now involves exploiting the > structure of *session* object, which is supposed to be considered > opaque. No, currently there is no such thing. Cheers, Edi. From jeffrey at cunningham.net Sun Dec 3 00:08:52 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Sat, 2 Dec 2006 16:08:52 -0800 Subject: [hunchentoot-devel] tbnl Message-ID: <20061203000852.GB15582@achilles.olympus.net> I wondering if I'm doing something wrong, or if the DELETE-SESSION-VALUE function is broken. I set some values using strings for symbols. They work fine with SESSION-VALUE, but if I try to use DELETE-SESSION-VALUE they're still there. I can null them out, but they're still show up as session values (of NULL). Has anyone else seen this behavior? Regards, --Jeff From edi at agharta.de Sun Dec 3 18:40:38 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 03 Dec 2006 19:40:38 +0100 Subject: [hunchentoot-devel] tbnl In-Reply-To: <20061203000852.GB15582@achilles.olympus.net> (Jeffrey Cunningham's message of "Sat, 2 Dec 2006 16:08:52 -0800") References: <20061203000852.GB15582@achilles.olympus.net> Message-ID: On Sat, 2 Dec 2006 16:08:52 -0800, Jeffrey Cunningham wrote: > I wondering if I'm doing something wrong, or if the > DELETE-SESSION-VALUE function is broken. I set some values using > strings for symbols. They work fine with SESSION-VALUE, but if I try > to use DELETE-SESSION-VALUE they're still there. > > I can null them out, but they're still show up as session values (of > NULL). Has anyone else seen this behavior? You can't use strings. The documentation says you're supposed to use symbols. Cheers, Edi. From jeffrey at cunningham.net Sun Dec 3 21:53:58 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Sun, 3 Dec 2006 13:53:58 -0800 Subject: [hunchentoot-devel] CMUCL vs SBCL: server speed Message-ID: <20061203215358.GA11244@achilles.olympus.net> I thought I'd share some observations concerning a big difference in server speed I've observered between CMUCL (19d) and SBCL (0.9.18). I've been working on a small website consisting of six or eight pages, each with mixed text and graphics (images from a few k up to 80k) using Hunchentoot as the server. Running it with CMUCL I noticed that the page load times were rather slow (2-5 seconds to all the images) I tried serving all the images out of ram (as in Edi's example), but it really made little differnce. It didn't matter whether I was browsing it via localhost or over the internet - the server was too slow for anything but a testbench. After the problems I had trying to get SSL to work with CMUCL, I decided to get the test site running with SBCL. (I hadn't worked with SBCL before, so it took some reworking). It was well worth the trouble: the page loading speed is now so fast I can't really measure it - fractions of a second. Question: does anyone know a way to profile handlers? I tried the usual method using TIME, but its alot of trouble trying to capture its output, and anyway it returns all 0 times and a few thousand cons', which is clearly not right. Regards, --Jeff From stesch at no-spoon.de Sun Dec 3 21:58:06 2006 From: stesch at no-spoon.de (Stefan Scholl) Date: Sun, 3 Dec 2006 22:58:06 +0100 Subject: [hunchentoot-devel] CMUCL vs SBCL: server speed In-Reply-To: <20061203215358.GA11244@achilles.olympus.net> References: <20061203215358.GA11244@achilles.olympus.net> Message-ID: <20061203215806.GV6643@parsec.no-spoon.de> On 2006-12-03 13:53:58, Jeffrey Cunningham wrote: > I've been working on a small website consisting of six or eight pages, > each with mixed text and graphics (images from a few k up to 80k) > using Hunchentoot as the server. Running it with CMUCL I noticed that > the page load times were rather slow (2-5 seconds to all the images) With (setf *print-pretty* nil) and (mp::startup-idle-and-top-level-loops)? -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ From edi at agharta.de Sun Dec 3 22:10:22 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 03 Dec 2006 23:10:22 +0100 Subject: [hunchentoot-devel] CMUCL vs SBCL: server speed In-Reply-To: <20061203215358.GA11244@achilles.olympus.net> (Jeffrey Cunningham's message of "Sun, 3 Dec 2006 13:53:58 -0800") References: <20061203215358.GA11244@achilles.olympus.net> Message-ID: On Sun, 3 Dec 2006 13:53:58 -0800, Jeffrey Cunningham wrote: > I thought I'd share some observations concerning a big difference in > server speed I've observered between CMUCL (19d) and SBCL (0.9.18). > > I've been working on a small website consisting of six or eight > pages, each with mixed text and graphics (images from a few k up to > 80k) using Hunchentoot as the server. Running it with CMUCL I > noticed that the page load times were rather slow (2-5 seconds to > all the images) http://common-lisp.net/pipermail/tbnl-devel/2005-August/000367.html http://common-lisp.net/pipermail/tbnl-devel/2005-October/000466.html Cheers, Edi. From penguin at ocean.vvo.ru Sun Dec 3 23:26:14 2006 From: penguin at ocean.vvo.ru (Igor Plekhov) Date: Mon, 4 Dec 2006 09:26:14 +1000 Subject: [hunchentoot-devel] CMUCL vs SBCL: server speed In-Reply-To: <20061203215358.GA11244@achilles.olympus.net> References: <20061203215358.GA11244@achilles.olympus.net> Message-ID: <20061203232613.GK25077@ocean.vvo.ru> On Sun, 03 Dec, 2006 at 13:53:58 -0800, Jeffrey Cunningham wrote: > > I've been working on a small website consisting of six or eight pages, > each with mixed text and graphics (images from a few k up to 80k) > using Hunchentoot as the server. Running it with CMUCL I noticed that > the page load times were rather slow (2-5 seconds to all the images) #+(and cmu mp) (setf mp::*idle-process* mp::*initial-process*) -- Registered Linux User #124759 From edi at agharta.de Mon Dec 4 07:30:14 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 04 Dec 2006 08:30:14 +0100 Subject: [hunchentoot-devel] CMUCL vs SBCL: server speed In-Reply-To: <20061203222452.GA12153@achilles.olympus.net> (Jeffrey Cunningham's message of "Sun, 3 Dec 2006 14:24:52 -0800") References: <20061203215358.GA11244@achilles.olympus.net> <20061203222452.GA12153@achilles.olympus.net> Message-ID: [Please use the mailing list.} On Sun, 3 Dec 2006 14:24:52 -0800, Jeffrey Cunningham wrote: > Hmmm. That's interesting. I just tried both at once and it killed > CMUCL (running under slime). I guess my unstable collection of CMUCL > + Slime + various CL packages don't all like each other yet. I think one of the links I sent talks about issues with SLIME. I'm sure Google will find something for you, but ISTR that the general wisdom is that these two don't mix well - the guys on the SLIME or CMUCL mailing list will probably know more about it. Cheers, Edi. From ch-tbnl at bobobeach.com Mon Dec 4 16:52:40 2006 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 4 Dec 2006 08:52:40 -0800 Subject: [hunchentoot-devel] dispatch-table request Message-ID: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> Edi, First of all, thanks for hunchentoot! I'm still getting used to it, but it seems great so far. But I do have a request. Would it be possible (and advisable) to extend the dispatch table to provide some metadata for each dispatcher? this could even be done in a backward compatible way by allowing the dispatchers in *dispatch-table* to be conses (or objects of an appropriately defined class) which would be examined as necessary, or just funcalled as they are presently, in the event that the dispatcher is just a lambda. This would facilitate debugging and modifying the dispatch table. Thanks, Cyrus From xach at xach.com Mon Dec 4 16:55:21 2006 From: xach at xach.com (Zach Beane) Date: Mon, 4 Dec 2006 11:55:21 -0500 Subject: [hunchentoot-devel] dispatch-table request In-Reply-To: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> Message-ID: <20061204165521.GE15105@xach.com> On Mon, Dec 04, 2006 at 08:52:40AM -0800, Cyrus Harmon wrote: > > Edi, > > First of all, thanks for hunchentoot! I'm still getting used to it, > but it seems great so far. But I do have a request. Would it be > possible (and advisable) to extend the dispatch table to provide some > metadata for each dispatcher? this could even be done in a backward > compatible way by allowing the dispatchers in *dispatch-table* to be > conses (or objects of an appropriately defined class) which would be > examined as necessary, or just funcalled as they are presently, in > the event that the dispatcher is just a lambda. This would facilitate > debugging and modifying the dispatch table. Why not make a dispatcher that does exactly what you want, and put it first in *dispatch-table*? Then you can have all kinds of non-default behavior, with no modifications to hunchentbnl. :) Zach From edi at agharta.de Mon Dec 4 17:04:11 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 04 Dec 2006 18:04:11 +0100 Subject: [hunchentoot-devel] dispatch-table request In-Reply-To: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> (Cyrus Harmon's message of "Mon, 4 Dec 2006 08:52:40 -0800") References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> Message-ID: On Mon, 4 Dec 2006 08:52:40 -0800, Cyrus Harmon wrote: > First of all, thanks for hunchentoot! I'm still getting used to it, > but it seems great so far. But I do have a request. Would it be > possible (and advisable) to extend the dispatch table to provide > some metadata for each dispatcher? this could even be done in a > backward compatible way by allowing the dispatchers in > *dispatch-table* to be conses (or objects of an appropriately > defined class) which would be examined as necessary, or just > funcalled as they are presently, in the event that the dispatcher is > just a lambda. This would facilitate debugging and modifying the > dispatch table. Hmm, ATM I cannot see how this would be useful. Do you have an example? From edi at agharta.de Mon Dec 4 17:04:53 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 04 Dec 2006 18:04:53 +0100 Subject: [hunchentoot-devel] dispatch-table request In-Reply-To: <20061204165521.GE15105@xach.com> (Zach Beane's message of "Mon, 4 Dec 2006 11:55:21 -0500") References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> <20061204165521.GE15105@xach.com> Message-ID: On Mon, 4 Dec 2006 11:55:21 -0500, Zach Beane wrote: > hunchentbnl Hey, don't mess with the name, or I'll have to sue you... From tobia.conforto at linux.it Mon Dec 4 19:27:11 2006 From: tobia.conforto at linux.it (Toby) Date: Mon, 4 Dec 2006 20:27:11 +0100 Subject: [hunchentoot-devel] dispatch-table request In-Reply-To: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> Message-ID: <20061204192711.GF1772@localhost.localdomain> Cyrus Harmon wrote: > extend the dispatch table to provide metadata for each dispatcher Quick way: you can use the documentation strings of the dispatchers to hold arbitrary metadata. You can usually put all kinds of stuff in a 'documentation string', in spite of its name, and get away with it. http://www.lisp.org/HyperSpec/Body/stagenfun_doc_umentationcp.html But! "Conforming programs should not depend for their correct behavior on the presence of those documentation strings. An implementation is permitted to discard documentation strings at any time..." So here's a standards-compliant way: put all your metadata into a global hash-table indexed on the dispatchers themselves. In either case I suggest writing your own create-...-dispatcher helper functions to populate the metadata. Toby From ch-tbnl at bobobeach.com Mon Dec 4 19:37:23 2006 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 4 Dec 2006 11:37:23 -0800 Subject: [hunchentoot-devel] dispatch-table request In-Reply-To: <20061204192711.GF1772@localhost.localdomain> References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> <20061204192711.GF1772@localhost.localdomain> Message-ID: <1149AF41-2D66-4EF7-ADAE-1C5882AEEC06@bobobeach.com> Thanks. As Toby and Zach pointed out, there are certainly multiple was to address this. I won't bother explaining a use-case for this kind of meta-data, as it's easy enough to add these in application- specific manner without modifying hunchentoot. Cyrus On Dec 4, 2006, at 11:27 AM, Toby wrote: > Cyrus Harmon wrote: >> extend the dispatch table to provide metadata for each dispatcher > > Quick way: you can use the documentation strings of the dispatchers to > hold arbitrary metadata. You can usually put all kinds of stuff in a > 'documentation string', in spite of its name, and get away with it. > > http://www.lisp.org/HyperSpec/Body/stagenfun_doc_umentationcp.html > > But! "Conforming programs should not depend for their correct > behavior > on the presence of those documentation strings. An implementation is > permitted to discard documentation strings at any time..." > > So here's a standards-compliant way: put all your metadata into a > global > hash-table indexed on the dispatchers themselves. > > In either case I suggest writing your own create-...-dispatcher helper > functions to populate the metadata. > > > Toby > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From phillip.m.jordan at gmail.com Mon Dec 4 19:58:14 2006 From: phillip.m.jordan at gmail.com (Phillip Jordan) Date: Mon, 04 Dec 2006 19:58:14 +0000 Subject: [hunchentoot-devel] dispatch-table request In-Reply-To: <20061204165521.GE15105@xach.com> References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> <20061204165521.GE15105@xach.com> Message-ID: <45747DD6.80505@gmail.com> Zach Beane wrote: > Why not make a dispatcher that does exactly what you want, and put it > first in *dispatch-table*? Then you can have all kinds of non-default > behavior, with no modifications to hunchentbnl. :) Another option would be to make your dispatchers closures and store your data that way. You can still use the standard dispatch table, and there is no restriction on the format or structure of the additional data either. phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From diesenbacher at gmail.com Mon Dec 4 20:00:29 2006 From: diesenbacher at gmail.com (Otto Diesenbacher) Date: Mon, 04 Dec 2006 21:00:29 +0100 Subject: [hunchentoot-devel] dispatch-table request References: <3E967FCC-8D7B-4E0A-AF9E-48ABFF02954C@bobobeach.com> Message-ID: <87k617ctya.fsf@gmail.com> Cyrus Harmon writes: > First of all, thanks for hunchentoot! I'm still getting used to it, > but it seems great so far. But I do have a request. Would it be > possible (and advisable) to extend the dispatch table to provide some > metadata for each dispatcher? this could even be done in a backward first, i am rather new to lisp, but perhaps my additions / changes to the hunchentoot:*dispatch-table* are useful or interesting for someone. (Please excuse the mixture of tbnl / hunchentoot naming in the following code) some stuff could propably be done better, much better :) feel free to criticise :) and finally: thanks to Edi and all the other people in the lisp-community, that produces so wonderful things like hunchentoot! :) ;; I wanted a *dispatch-table*, so that I can add, remove or update the ;; dispatch-functions while a hunchentoot-server is running. ;; ;; f.e. my dispatch-table looks like: ;; CL-USER> hunchentoot:*dispatch-table* ;; (("/web/log" #) ;; ("/web/error.html" #) ;; ("/web/index.html" #) ;; ("/web/style.css" #) ;; ("default" #)) ;; i redefined the method. Both types of entries should work (plain ;; function, as in the "original" hunchentoot and my "new" entries ;; '("somestring" #function)). The "somestring" is later used to identify ;; the dispatch function. ;;; Redefined original hunchentoot:dispatch-request (defmethod dispatch-request (dispatch-table) "Dispatches *REQUEST* based upon rules in the DISPATCH-TABLE. This method provides the default tbnl/hunchentoot behavior." (loop for dispatcher in dispatch-table for action = (if (typep dispatcher 'list) (funcall (cadr dispatcher) *request*) (funcall dispatcher *request*)) when action return (funcall action) finally (setf (return-code *reply*) +http-not-found+))) ;; and use the following functions to work with the "new" dispatch-table (defun safe-assoc-string (item list) (loop for i in list when (if (and (listp i) (stringp (car i))) (string= (car i) item)) return i)) (defun add-dispatcher (path function) "adds dispatcher to tbnl:*dispatch-table*" (if (safe-assoc-string path hunchentoot:*dispatch-table*) ;;there is already a dispatcher with that identifier (setf (cadr (safe-assoc-string path tbnl:*dispatch-table*)) function) ;;create a new entry (push (list path function) tbnl:*dispatch-table*))) (defun add-dispatcher-prefix (path function) "convient way to construct a dispatcher with prefix." in a lambda to call the statistic writer before." (add-dispatcher path (funcall #'tbnl:create-prefix-dispatcher path #'(lambda () ;; (write-statistic tbnl:*request*) ; my statistics function (funcall function))))) (defun remove-dispatcher (path) "remove a dispatch-entry by their path" (setf tbnl:*dispatch-table* (remove (assoc path tbnl:*dispatch-table* :test #'string=) tbnl:*dispatch-table*))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; additionally i made the following macros, so that i simply have to evaluate f.e. ;; ;; (defweb "/my/page.html" ;; (bla ;; (bla ....))) ;; ;; or for webpages that need parameters ;; ;; (defweb* "/my/page.html" (firstparameter secondparameter) ;; (bla ;; (setf firstparameter 'new-value) ;; (...))) ;; ;; and the function that listen at the path "/my/page.html" is created or updated ;; ;; ;; the macros (and some condition-stuff i use): (define-condition web-error (error) ((message :initarg :message :reader message))) (defmacro error-page (fehler) `(tbnl:redirect (format nil "/web/error.html?fehler=~A" (tbnl:url-encode ,fehler)))) (defmacro defweb (path &body body) "constructs a defun + entry into tbnl:*dispatch-table*" (let ((funcn (read-from-string path))) `(progn (defun ,funcn () (handler-case (progn , at body) (web-error (fehler) (web:error-page (message fehler))))) (compile (quote ,funcn)) (add-dispatcher-prefix ,path (function ,funcn))))) (defmacro defweb* (path parameters &body body) "constructs a defun + entry into tbnl:*dispatch-table* and prepares local variables coresponding to the parameters. f.e. (web:defweb* \"/web/test\" (a) (format nil \"~A\" a)) it is also possible to prepare a conversion of the variable. Put the definition in extra brackets. f.e. (web:defweb* \"/web/test\" ((a #'parse-integer)) (format nil \"type of a ~A\" (type-of a))) " (let ((funcn (read-from-string (string path)))) `(progn (defun ,funcn ,(if parameters (append '(&aux ) (loop for i in parameters collect (if (listp i) `(,(car i) (funcall ,(cadr i) (tbnl:parameter ,(string-downcase (string (car i)))))) `(,i (tbnl:parameter ,(string-downcase (string i)))))))) (handler-case (progn , at body) (web-error (fehler) (web:error-page (message fehler))))) (compile (quote ,funcn)) (add-dispatcher-prefix ,path (function ,funcn)) ',funcn))) best regards okflo -- Otto Diesenbacher diesenbacher at gmail.com Salzburg, ?sterreich From ch-tbnl at bobobeach.com Mon Dec 4 20:42:08 2006 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 4 Dec 2006 12:42:08 -0800 Subject: [hunchentoot-devel] global dispatch-table Message-ID: <9C49843A-84EB-49EC-A308-CB49755D9F10@bobobeach.com> What's the rationale behind a global dispatch table? It seems like it might be nicer to have a per-server dispatch table. I can't imagine that there would be a good reason not have access to the server object when accessing *dispatch-table*, although as currently structured process-request should probably take an additional argument for the server. Thanks, Cyrus From edi at agharta.de Mon Dec 4 20:51:54 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 04 Dec 2006 21:51:54 +0100 Subject: [hunchentoot-devel] global dispatch-table In-Reply-To: <9C49843A-84EB-49EC-A308-CB49755D9F10@bobobeach.com> (Cyrus Harmon's message of "Mon, 4 Dec 2006 12:42:08 -0800") References: <9C49843A-84EB-49EC-A308-CB49755D9F10@bobobeach.com> Message-ID: On Mon, 4 Dec 2006 12:42:08 -0800, Cyrus Harmon wrote: > What's the rationale behind a global dispatch table? It seems like > it might be nicer to have a per-server dispatch table. I can't > imagine that there would be a good reason not have access to the > server object when accessing *dispatch-table*, although as currently > structured process-request should probably take an additional > argument for the server. The rationale is that it's a leftover from the times when Hunchentoot was (based on) TBNL and TBNL was a single-server library. Have you seen *META-DISPATCHER*? http://weitz.de/hunchentoot/#*meta-dispatcher* Note that you always have access to the server object via the *SERVER* variable. Cheers, Edi. From edi at agharta.de Tue Dec 5 23:58:23 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 06 Dec 2006 00:58:23 +0100 Subject: [hunchentoot-devel] global dispatch-table In-Reply-To: (Edi Weitz's message of "Mon, 04 Dec 2006 21:51:54 +0100") References: <9C49843A-84EB-49EC-A308-CB49755D9F10@bobobeach.com> Message-ID: On Mon, 04 Dec 2006 21:51:54 +0100, Edi Weitz wrote: > The rationale is that it's a leftover from the times when > Hunchentoot was (based on) TBNL and TBNL was a single-server > library. Let me add that with hindsight I think this is the right decision. Yes, with Hunchentoot you /can/ have multiple servers, but I don't think it makes sense to view Hunchentoot as a content-agnostic workhorse like Apache. I prefer to view it as a building block for creating application servers, and if you have more than one server in the same image, I think it is very likely that what these servers serve will be related. Thus, a global dispatch table makes sense to me. If it doesn't make sense to you, there's *META-DISPATCHER*, as I said. Cheers, Edi. From nablaone at gmail.com Wed Dec 6 21:24:39 2006 From: nablaone at gmail.com (=?UTF-8?Q?Rafa=C5=82_Strzali=C5=84ski?=) Date: Wed, 6 Dec 2006 22:24:39 +0100 Subject: [hunchentoot-devel] Problems with create-folder-dispatcher-and-handler In-Reply-To: References: Message-ID: Hi, I've tried to serve files from 'public' directory under '/' base URL: (hunchentoot::create-folder-dispatcher-and-handler "/" #p"public/") and always got 403 HTTP error. When I've changed base url to for example '/public/' everything works fine. I've tried to fix it, but i'm don't understand pathnames well :-( Any ideas? IMHO (with-chroot (directory) ...) would be an ideal solution :-) Environment: SBCL 1.0 Debian Etch Hunchentoot 0.4.10 -- Best regards, Rafal Strzalinski (nabla) http://rafal.strzalinski.pl From edi at agharta.de Thu Dec 7 07:49:27 2006 From: edi at agharta.de (Edi Weitz) Date: Thu, 07 Dec 2006 08:49:27 +0100 Subject: [hunchentoot-devel] Problems with create-folder-dispatcher-and-handler In-Reply-To: =?utf-8?q?=28Rafa=C5=82_Strzali=C5=84ski's?= message of "Wed, 6 Dec 2006 22:24:39 +0100") References: Message-ID: On Wed, 6 Dec 2006 22:24:39 +0100, "Rafa? Strzali?ski" wrote: > I've tried to serve files from 'public' directory under '/' base URL: > > (hunchentoot::create-folder-dispatcher-and-handler > "/" > #p"public/") Why the double colon? > and always got 403 HTTP error. > > When I've changed base url to for example '/public/' everything > works fine. > > I've tried to fix it, but i'm don't understand pathnames well :-( > > Any ideas? I just tried with LispWorks and it works fine for me. What happens if you use an absolute pathname instead of #p"public/"? Note that the documentation says that a file relative to BASE-PATH is emitted, specifically, if you look at the source code, MERGE-PATHNAMES is used. MERGE-PATHNAMES is called in the handler's thread and I think it's implementation-specific what happens if you use a relative pathname here. So, don't do it... > IMHO > (with-chroot (directory) ...) would be an ideal solution :-) Huh? Cheers, Edi. From quasilists at gmail.com Thu Dec 7 08:55:03 2006 From: quasilists at gmail.com (quasi) Date: Thu, 07 Dec 2006 14:25:03 +0530 Subject: [hunchentoot-devel] tbnl-worker threads Message-ID: <87zma0jdaw.fsf@agni4.cltp.com> Hey, We are using Apache+mod_lisp2+TBNL for our website. The load has sorta spiked of late, we serve approx 4-5 concurrent pages (which are heavy, computationally and in size). We are using Allegro CL. The thing observed is that there are about 70-100 tbnl-worker threads which I dont think are doing anything much. There is a limit of 230 threads on the Allegro CL and this 100 threads becomes worrysome. I think they have a timeout and the die eventually, but I wonder at their existance and if they could be made to die an early death (I could give them some cig's but ...). :) BTW is it good time to move from TBNL -> Hunchentoot ? Because it's a live system and 'if it aint broke dont fix it' comes to me mind. Any ideas about the performance etc. ? I did some initial benchmarks and seems to be a tad slower than apache+mod_lisp2+TBNL ... but the benchmarks were not serious. I will do them again. thanks, -- quasi Utopia Unlimited! From edi at agharta.de Thu Dec 7 09:09:30 2006 From: edi at agharta.de (Edi Weitz) Date: Thu, 07 Dec 2006 10:09:30 +0100 Subject: [hunchentoot-devel] tbnl-worker threads In-Reply-To: <87zma0jdaw.fsf@agni4.cltp.com> (quasi's message of "Thu, 07 Dec 2006 14:25:03 +0530") References: <87zma0jdaw.fsf@agni4.cltp.com> Message-ID: On Thu, 07 Dec 2006 14:25:03 +0530, quasi wrote: > We are using Apache+mod_lisp2+TBNL for our website. The load has > sorta spiked of late, we serve approx 4-5 concurrent pages (which > are heavy, computationally and in size). We are using Allegro CL. > > The thing observed is that there are about 70-100 tbnl-worker > threads which I dont think are doing anything much. There is a > limit of 230 threads on the Allegro CL and this 100 threads becomes > worrysome. I think they have a timeout and the die eventually, but I > wonder at their existance and if they could be made to die an early > death (I could give them some cig's but ...). :) In Hunchentoot, you should be able to use the READ-TIMEOUT parameter of START-SERVER to control how long worker threads are supposed to live if they're idle. In TBNL, things are a bit muddled due to the usage of KMRCL - you have to find out yourself depending on your implementation. > BTW is it good time to move from TBNL -> Hunchentoot ? Because it's > a live system and 'if it aint broke dont fix it' comes to me mind. If you have a live system that's working fine with TBNL, then don't switch. I think in that case it's better to be safe than sorry... :) But note that there won't be any improvements or bugfixes for TBNL in the future. > Any ideas about the performance etc. ? I did some initial > benchmarks and seems to be a tad slower than apache+mod_lisp2+TBNL > ... but the benchmarks were not serious. I will do them again. ATM, Hunchentoot is definitely slower than TBNL, see recent postings (last month?) to this list. I have patched FLEXI-STREAMS to improve Hunchentoot performance, but I haven't yet found the time to test and commit these changes. I doubt that the performance differences really matter for you with five concurrent pages, though. Cheers, Edi. From mlist at rogers.com Sat Dec 16 03:01:36 2006 From: mlist at rogers.com (vedm) Date: Fri, 15 Dec 2006 22:01:36 -0500 Subject: [hunchentoot-devel] I/O timeout error (SBCL) Message-ID: When I set *catch-errors-p* to nil I often see this error in the debugger: == I/O timeout reading # [Condition of type SB-SYS:IO-TIMEOUT] == even though I still get my pages in the browser. Any idea why this happens? -- vedm From edi at agharta.de Sat Dec 16 10:26:12 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 16 Dec 2006 11:26:12 +0100 Subject: [hunchentoot-devel] I/O timeout error (SBCL) In-Reply-To: (vedm's message of "Fri, 15 Dec 2006 22:01:36 -0500") References: Message-ID: On Fri, 15 Dec 2006 22:01:36 -0500, vedm wrote: > When I set *catch-errors-p* to nil I often see this error in the > debugger: > > == > I/O timeout reading # > [Condition of type SB-SYS:IO-TIMEOUT] > == > > even though I still get my pages in the browser. > > Any idea why this happens? What happens if you set *CATCH-ERRORS-P* to T? Can you send a backtrace? Which SBCL version? Which operating system? From mlist at rogers.com Sat Dec 16 19:18:03 2006 From: mlist at rogers.com (vedm) Date: Sat, 16 Dec 2006 14:18:03 -0500 Subject: [hunchentoot-devel] I/O timeout error (SBCL) References: Message-ID: Edi Weitz writes: > On Fri, 15 Dec 2006 22:01:36 -0500, vedm wrote: > >> When I set *catch-errors-p* to nil I often see this error in the >> debugger: >> >> == >> I/O timeout reading # >> [Condition of type SB-SYS:IO-TIMEOUT] >> == >> >> even though I still get my pages in the browser. >> >> Any idea why this happens? > > What happens if you set *CATCH-ERRORS-P* to T? Can you send a > backtrace? Which SBCL version? Which operating system? If I set *CATCH-ERRORS-P* to T I do not see this error. Note that even when I see this error I still get response from Hunchentoot. I am on a Debian system: CL-USER> (format t "Lisp implementation: ~A ~A~%OS: ~A ~A~%CPU: ~A ~A~%" (lisp-implementation-type) (lisp-implementation-version) (software-type) (software-version) (machine-type) (machine-version)) Lisp implementation: SBCL 1.0 OS: Linux 2.6.17-2-686 CPU: X86 AMD Athlon(tm) XP 2200+ And here is the backtrace: ===== I/O timeout reading # [Condition of type SB-SYS:IO-TIMEOUT] Restarts: 0: [USE-VALUE] Specify a character to be used instead. 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #) 1: (SWANK::CALL-WITH-BINDINGS ((*PRINT-PRETTY*) (*PRINT-LEVEL* . 4) (*PRINT-LENGTH* . 10) (*PRINT-CIRCLE* . T) (*PRINT-READABLY*) (*PRINT-PPRINT-DISPATCH* . #) (*PRINT-GENSYM* . T) (*PRINT-BASE* . 10) (*PRINT-RADIX*) (*PRINT-ARRAY* . T) ...) #) 2: (SWANK::DEBUG-IN-EMACS #) 3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) # #) 4: (SWANK::CALL-WITH-REDIRECTED-IO # #) 5: (SWANK::CALL-WITH-CONNECTION # #) 6: (INVOKE-DEBUGGER #) 7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #) 8: (SIGNAL #) 9: (ERROR SB-SYS:IO-TIMEOUT) 10: (SB-IMPL::REFILL-BUFFER/FD #) 11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE # NIL :EOF) 12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM)) (#(8 9) . #()) # #) 13: (FLEXI-STREAMS::READ-BYTE* # NIL) 14: (FLEXI-STREAMS::READ-CHAR-8-BIT # #(0 1 2 3 4 5 6 7 8 9 ...)) 15: ((FLET FLEXI-STREAMS::GET-CHAR-CODE)) 16: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) # # #) 17: ((SB-PCL::FAST-METHOD STREAM-PEEK-CHAR (FUNDAMENTAL-CHARACTER-INPUT-STREAM)) # # #) 18: (PEEK-CHAR NIL # T NIL #) 19: (CHUNGA:READ-LINE* # NIL) 20: (HUNCHENTOOT::GET-REQUEST-DATA) 21: (HUNCHENTOOT::PROCESS-CONNECTION # #) 22: ((LAMBDA NIL)) 23: ("foreign function: call_into_lisp") 24: ("foreign function: funcall0") 25: ("foreign function: new_thread_trampoline") 26: ("foreign function: #xA7FAF0BD") ====== -- vedm From edi at agharta.de Sat Dec 16 21:00:05 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 16 Dec 2006 22:00:05 +0100 Subject: [hunchentoot-devel] I/O timeout error (SBCL) In-Reply-To: (vedm's message of "Sat, 16 Dec 2006 14:18:03 -0500") References: Message-ID: On Sat, 16 Dec 2006 14:18:03 -0500, vedm wrote: > If I set *CATCH-ERRORS-P* to T I do not see this error. Strange, and how did you get the backtrace then? > I/O timeout reading # > [Condition of type SB-SYS:IO-TIMEOUT] > > Restarts: > 0: [USE-VALUE] Specify a character to be used instead. > 1: [TERMINATE-THREAD] Terminate this thread (#) > > Backtrace: > 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #) > 1: (SWANK::CALL-WITH-BINDINGS ((*PRINT-PRETTY*) (*PRINT-LEVEL* . 4) (*PRINT-LENGTH* . 10) (*PRINT-CIRCLE* . T) (*PRINT-READABLY*) (*PRINT-PPRINT-DISPATCH* . #) (*PRINT-GENSYM* . T) (*PRINT-BASE* . 10) (*PRINT-RADIX*) (*PRINT-ARRAY* . T) ...) #) > 2: (SWANK::DEBUG-IN-EMACS #) > 3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) # #) > 4: (SWANK::CALL-WITH-REDIRECTED-IO # #) > 5: (SWANK::CALL-WITH-CONNECTION # #) > 6: (INVOKE-DEBUGGER #) > 7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #) > 8: (SIGNAL #) > 9: (ERROR SB-SYS:IO-TIMEOUT) > 10: (SB-IMPL::REFILL-BUFFER/FD #) > 11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE # NIL :EOF) > 12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM)) (#(8 9) . #()) # #) > 13: (FLEXI-STREAMS::READ-BYTE* # NIL) > 14: (FLEXI-STREAMS::READ-CHAR-8-BIT # #(0 1 2 3 4 5 6 7 8 9 ...)) > 15: ((FLET FLEXI-STREAMS::GET-CHAR-CODE)) > 16: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) # # #) > 17: ((SB-PCL::FAST-METHOD STREAM-PEEK-CHAR (FUNDAMENTAL-CHARACTER-INPUT-STREAM)) # # #) > 18: (PEEK-CHAR NIL # T NIL #) > 19: (CHUNGA:READ-LINE* # NIL) > 20: (HUNCHENTOOT::GET-REQUEST-DATA) > 21: (HUNCHENTOOT::PROCESS-CONNECTION # #) > 22: ((LAMBDA NIL)) > 23: ("foreign function: call_into_lisp") > 24: ("foreign function: funcall0") > 25: ("foreign function: new_thread_trampoline") > 26: ("foreign function: #xA7FAF0BD") I think this is a worker thread which dies from a timeout after having been idle for some time (i.e. after trying to read from his stream in vain). It looks as if the main problem is that these errors shouldn't be logged. I'll have to investigate this when I have more time. Cheers, Edi. From mlist at rogers.com Sat Dec 16 22:27:33 2006 From: mlist at rogers.com (vedm) Date: Sat, 16 Dec 2006 17:27:33 -0500 Subject: [hunchentoot-devel] I/O timeout error (SBCL) References: Message-ID: Edi Weitz writes: > On Sat, 16 Dec 2006 14:18:03 -0500, vedm wrote: > >> If I set *CATCH-ERRORS-P* to T I do not see this error. > > Strange, and how did you get the backtrace then? That backtrace appears only when *CATCH-ERRORS-P* is set to nil (not to T). -- vedm From edi at agharta.de Sat Dec 16 22:42:44 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 16 Dec 2006 23:42:44 +0100 Subject: [hunchentoot-devel] I/O timeout error (SBCL) In-Reply-To: (vedm's message of "Sat, 16 Dec 2006 17:27:33 -0500") References: Message-ID: On Sat, 16 Dec 2006 17:27:33 -0500, vedm wrote: > Edi Weitz writes: > >> On Sat, 16 Dec 2006 14:18:03 -0500, vedm wrote: >> >>> If I set *CATCH-ERRORS-P* to T I do not see this error. >> >> Strange, and how did you get the backtrace then? > > That backtrace appears only when *CATCH-ERRORS-P* is set to nil (not > to T). Sorry, I was confused... :) Basically, mx explanation in the other email was right except for the logging part. There should /probably/ be some cleanup that prevents errors like this one (that aren't really errors) to pop up the debugger. From jcm at FreeBSD-uk.eu.org Mon Dec 18 17:14:59 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Mon, 18 Dec 2006 17:14:59 +0000 Subject: [hunchentoot-devel] Starting a server hangs Message-ID: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> Hi all, I'm experimenting with hunchentoot with a view to porting my web app. I have 0.4.11 running on SBCL-1.0 and Ubuntu Linux. I have a default handler set up, and call: (hunchentoot:start-server :port 8888) and it works fine. However, when I call the above function from inside the startup sequence of the asdf system that loads the app, it hangs. What am I doing wrong here? Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Mon Dec 18 17:35:48 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 18 Dec 2006 18:35:48 +0100 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Mon, 18 Dec 2006 17:14:59 +0000") References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> Message-ID: On Mon, 18 Dec 2006 17:14:59 +0000, Jonathon McKitrick wrote: > I'm experimenting with hunchentoot with a view to porting my web > app. I have 0.4.11 running on SBCL-1.0 and Ubuntu Linux. > > I have a default handler set up, and call: > (hunchentoot:start-server :port 8888) > > and it works fine. > > However, when I call the above function from inside the startup > sequence of the asdf system that loads the app, it hangs. > > What am I doing wrong here? You should send real code so we can see what you're doing. FWIW, I don't know what you mean with "from inside the startup sequence." > My other computer is your Windows box. I doubt that... Cheers, Edi. From jcm at FreeBSD-uk.eu.org Mon Dec 18 18:03:19 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Mon, 18 Dec 2006 18:03:19 +0000 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> Message-ID: <20061218180319.GA62698@dogma.freebsd-uk.eu.org> On Mon, Dec 18, 2006 at 06:35:48PM +0100, Edi Weitz wrote: : On Mon, 18 Dec 2006 17:14:59 +0000, Jonathon McKitrick wrote: : : > I'm experimenting with hunchentoot with a view to porting my web : > app. I have 0.4.11 running on SBCL-1.0 and Ubuntu Linux. : > : > I have a default handler set up, and call: : > (hunchentoot:start-server :port 8888) : > : > and it works fine. : > : > However, when I call the above function from inside the startup : > sequence of the asdf system that loads the app, it hangs. : > : > What am I doing wrong here? : : You should send real code so we can see what you're doing. FWIW, I : don't know what you mean with "from inside the startup sequence." Well, it's difficult to simulate, but I'll try. The last file loaded by asdf does this: (defun rlg-start () "Entry point after loading via asdf/require." (db:connect-to-rlg) (ajax:rlg-web-start :port 9000)) (rlg-start) ------------------------ And another file has this: (in-package :ajax) (defparameter *rlg-server* nil) (defun rlg-web-start (&key port) "Start the server, initialize dispatch table." (setf *dispatch-table* (list (create-static-file-dispatcher-and-handler "/index.html" #P "web/ah01/") 'default-dispatcher)) (format t "; --> Starting...~%") (setf *rlg-server* (hunchentoot:start-server :port 4242)) (format t "; --> Ready!~%")) Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Mon Dec 18 19:27:29 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 18 Dec 2006 20:27:29 +0100 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: <20061218180319.GA62698@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Mon, 18 Dec 2006 18:03:19 +0000") References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> Message-ID: On Mon, 18 Dec 2006 18:03:19 +0000, Jonathon McKitrick wrote: > (ajax:rlg-web-start :port 9000)) > > [...] > > (setf *rlg-server* (hunchentoot:start-server :port 4242)) You're sure the above is not the culprit? Other than that, what you sent is not a self-contained test case. Send something that I can just use with instructions how to reproduce the faulty behaviour. Cheers, Edi. From jcm at FreeBSD-uk.eu.org Mon Dec 18 20:12:45 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Mon, 18 Dec 2006 20:12:45 +0000 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> Message-ID: <20061218201245.GA63537@dogma.freebsd-uk.eu.org> On Mon, Dec 18, 2006 at 08:27:29PM +0100, Edi Weitz wrote: : On Mon, 18 Dec 2006 18:03:19 +0000, Jonathon McKitrick wrote: : : > (ajax:rlg-web-start :port 9000)) : > : > [...] : > : > (setf *rlg-server* (hunchentoot:start-server :port 4242)) : : You're sure the above is not the culprit? : : Other than that, what you sent is not a self-contained test case. : Send something that I can just use with instructions how to reproduce : the faulty behaviour. Okay, I'm attaching 2 small files. If you start sbcl, load hunchentoot, then load hunchentoot-start.lisp, the server will start and all is well. If you start sbcl, then load test-hunchentoot.asd, the system will hang at the start-server call. Jonathon McKitrick -- My other computer is your Windows box. -------------- next part -------------- (in-package :cl-user) (defparameter *rlg-server* nil) (defun rlg-web-start (&key port) "Start the server, initialize dispatch table." (setf hunchentoot:*dispatch-table* (list (hunchentoot:create-static-file-dispatcher-and-handler "/index.html" #P "web/ah01/") 'hunchentoot:default-dispatcher)) (format t "; --> Starting...~%") (setf *rlg-server* (hunchentoot:start-server :port port)) (format t "; --> Ready!~%")) (rlg-web-start :port 9000) -------------- next part -------------- ;; -*- mode: lisp; encoding: utf-8 -*- ;; Copyright ?? 2006 Jonathon McKitrick. All Rights Reserved. (defpackage :rlg-system (:use :cl :asdf)) (in-package :rlg-system) (defsystem test-hunchentoot :components ((:file "hunchentoot-start")) :depends-on (:hunchentoot :clsql :cl-pdf :cl-typesetting :html-template)) From edi at agharta.de Mon Dec 18 20:32:52 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 18 Dec 2006 21:32:52 +0100 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: <20061218201245.GA63537@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Mon, 18 Dec 2006 20:12:45 +0000") References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> <20061218201245.GA63537@dogma.freebsd-uk.eu.org> Message-ID: On Mon, 18 Dec 2006 20:12:45 +0000, Jonathon McKitrick wrote: > Okay, I'm attaching 2 small files. If you start sbcl, load > hunchentoot, then load hunchentoot-start.lisp, the server will start > and all is well. > > If you start sbcl, then load test-hunchentoot.asd, the system will > hang at the start-server call. Yes, I can reproduce it now, thanks. Actually, you don't even need ASDF - just COMPILE-FILE hunchentoot-start.lisp and LOAD the resulting FASL file, and SBCL hangs. This doesn't happen with LispWorks, though. At the moment, I have no idea what the problem is. Maybe an SBCL expert is reading this and can help. Cheers, Edi. From tbnl at rojoma.com Mon Dec 18 22:09:27 2006 From: tbnl at rojoma.com (Robert J. Macomber) Date: Mon, 18 Dec 2006 15:09:27 -0700 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> <20061218201245.GA63537@dogma.freebsd-uk.eu.org> Message-ID: <20061218220927.GA1146@oja.no> On Mon, Dec 18, 2006 at 09:32:52PM +0100, Edi Weitz wrote: > This doesn't happen with LispWorks, though. At the moment, I have no > idea what the problem is. Maybe an SBCL expert is reading this and > can help. Definitely an SBCL bug. Paring it down, it's hanging at the call to make-instance -- it looks like any make-instance will do, it's not something socket-specific. That is, this is a minimal testcase which shows the problem is: (defclass foo () ()) (defun foo (&aux done) (flet ((do-it () (make-instance 'foo) (setf done t))) (sb-thread:make-thread #'do-it) (loop until done do (sleep 0.1)))) (foo) Remove the make-instance, and it terminates. Move the make-instance into the main thread, and it terminates. Leave it there, it hangs (and never gets to the point of running things like shared-initialize or lsof would report the socket is created). CC'd sbcl-devel, since getting into CLOS+thread bugs is way beyond my level of SBCL knowledge. I hope that's an open list, as I'm not subscribed there with this address. For those on that list but not tbnl-devel: compile-file + load'ing the above snippet hangs SBCL. -- Robert Macomber tbnl at rojoma.com From tbnl at rojoma.com Mon Dec 18 22:24:09 2006 From: tbnl at rojoma.com (Robert J. Macomber) Date: Mon, 18 Dec 2006 15:24:09 -0700 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: <20061218220927.GA1146@oja.no> References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> <20061218201245.GA63537@dogma.freebsd-uk.eu.org> <20061218220927.GA1146@oja.no> Message-ID: <20061218222409.GB1146@oja.no> >From sbcl-devel: > Loading a FASL file takes the big compiler lock. The first call to > MAKE-INSTANCE in compiled code with constant class-name and initargs > compiles an optimized constructor (a "ctor"). The end. So I guess the answer is "don't do that then", at least for now. Putting your startup call in a :after method on asdf:perform doesn't seem to work either, but deferring the startup into a thread of its own (i.e., instead of a toplevel (startup) do (make-thread 'startup)) lets the locks all get released. -- Robert Macomber tbnl at rojoma.com From jcm at FreeBSD-uk.eu.org Mon Dec 18 22:45:49 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Mon, 18 Dec 2006 22:45:49 +0000 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: <20061218222409.GB1146@oja.no> References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> <20061218201245.GA63537@dogma.freebsd-uk.eu.org> <20061218220927.GA1146@oja.no> <20061218222409.GB1146@oja.no> Message-ID: <20061218224549.GA64280@dogma.freebsd-uk.eu.org> On Mon, Dec 18, 2006 at 03:24:09PM -0700, Robert J. Macomber wrote: : seem to work either, but deferring the startup into a thread of its Thank you all for your help. Whether the bug (if it is, in fact, a bug) gets fixed or not, I can solve the problem. Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Mon Dec 18 22:57:54 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 18 Dec 2006 23:57:54 +0100 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: <20061218222409.GB1146@oja.no> (Robert J. Macomber's message of "Mon, 18 Dec 2006 15:24:09 -0700") References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> <20061218201245.GA63537@dogma.freebsd-uk.eu.org> <20061218220927.GA1146@oja.no> <20061218222409.GB1146@oja.no> Message-ID: On Mon, 18 Dec 2006 15:24:09 -0700, "Robert J. Macomber" wrote: > So I guess the answer is "don't do that then", at least for now. > Putting your startup call in a :after method on asdf:perform doesn't > seem to work either, but deferring the startup into a thread of its > own (i.e., instead of a toplevel (startup) do (make-thread > 'startup)) lets the locks all get released. Ah, OK. Thanks for the detective work. By coincidence I came across a similar case last Friday. Another, SBCL-specific, workaround is to add a file precompile.lisp to your ASDF system definition that is guaranteed to be the very last file to be compiled and loaded (and that is also guaranteed to be re-compiled whenever something changes in the rest of the system). This file should contain only one form: (sb-pcl::precompile-random-code-segments) I don't think this is documented or officially endorsed by the SBCL developers, but it should pre-compile optimized constructors and other CLOS functions. From jcm at FreeBSD-uk.eu.org Tue Dec 19 00:00:49 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Tue, 19 Dec 2006 00:00:49 +0000 Subject: [hunchentoot-devel] Other http methods allowed? Message-ID: <20061219000049.GA64660@dogma.freebsd-uk.eu.org> I did not see specifically if the other http methods PUT and DELETE are supported. If not, is it correct to assume they could be easily added? Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Tue Dec 19 00:12:03 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 19 Dec 2006 01:12:03 +0100 Subject: [hunchentoot-devel] Other http methods allowed? In-Reply-To: <20061219000049.GA64660@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Tue, 19 Dec 2006 00:00:49 +0000") References: <20061219000049.GA64660@dogma.freebsd-uk.eu.org> Message-ID: On Tue, 19 Dec 2006 00:00:49 +0000, Jonathon McKitrick wrote: > I did not see specifically if the other http methods PUT and DELETE > are supported. Hunchentoot has no special support for GET and POST either, or for MKCOL, PROPFIND, and so on. The only method that gets special treatment right now is HEAD for obvious reasons. It is up to the application programmer to support certain methods. > If not, is it correct to assume they could be easily added? Depends on the semantics you want to have. If for example you want to write a WebDAV server, there remains quite a lot for you to do. Believe me, I once wrote one... :) Cheers, Edi. From jcm at FreeBSD-uk.eu.org Tue Dec 19 14:34:09 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Tue, 19 Dec 2006 14:34:09 +0000 Subject: [hunchentoot-devel] Other http methods allowed? In-Reply-To: References: <20061219000049.GA64660@dogma.freebsd-uk.eu.org> Message-ID: <20061219143409.GA69401@dogma.freebsd-uk.eu.org> On Tue, Dec 19, 2006 at 01:12:03AM +0100, Edi Weitz wrote: : On Tue, 19 Dec 2006 00:00:49 +0000, Jonathon McKitrick wrote: : : > I did not see specifically if the other http methods PUT and DELETE : > are supported. : : Hunchentoot has no special support for GET and POST either, or for : MKCOL, PROPFIND, and so on. The only method that gets special : treatment right now is HEAD for obvious reasons. It is up to the : application programmer to support certain methods. As long as it doesn't disallow them, that should be fine. Then I can just branch on each method within the general handler for that URL. : > If not, is it correct to assume they could be easily added? : : Depends on the semantics you want to have. If for example you want to : write a WebDAV server, there remains quite a lot for you to do. : Believe me, I once wrote one... :) Fortunately, it's not quite that bad. ;-) I use XMLHttpRequest with those 4 http methods for REST calls. Can that be supported without the level of work needed for a WebDAV server? Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Tue Dec 19 14:43:30 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 19 Dec 2006 15:43:30 +0100 Subject: [hunchentoot-devel] Other http methods allowed? In-Reply-To: <20061219143409.GA69401@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Tue, 19 Dec 2006 14:34:09 +0000") References: <20061219000049.GA64660@dogma.freebsd-uk.eu.org> <20061219143409.GA69401@dogma.freebsd-uk.eu.org> Message-ID: On Tue, 19 Dec 2006 14:34:09 +0000, Jonathon McKitrick wrote: > I use XMLHttpRequest with those 4 http methods for REST calls. Can > that be supported without the level of work needed for a WebDAV > server? I think only you can answer this question. I don't know what the methods are supposed to do for you. From jeffrey at cunningham.net Wed Dec 20 04:12:23 2006 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Tue, 19 Dec 2006 20:12:23 -0800 Subject: [hunchentoot-devel] Starting a server hangs In-Reply-To: References: <20061218171459.GA62437@dogma.freebsd-uk.eu.org> <20061218180319.GA62698@dogma.freebsd-uk.eu.org> <20061218201245.GA63537@dogma.freebsd-uk.eu.org> <20061218220927.GA1146@oja.no> <20061218222409.GB1146@oja.no> Message-ID: <4588B827.9010609@cunningham.net> I'm baffled. I'm running SBCL 1.0 on a Gentoo system and it works perfectly for me. I cannot make your test case hang. -jeff From jcm at FreeBSD-uk.eu.org Wed Dec 20 06:36:35 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Wed, 20 Dec 2006 06:36:35 +0000 Subject: [hunchentoot-devel] Preferred method for login? Message-ID: <20061220063635.GA75037@dogma.freebsd-uk.eu.org> I was searching the mailing list and ran across a couple of ways to set up authorized handlers. Is there an 'official' or recommended way of doing this that works best in practice? Or is there really no wrong way to do it as long as it works? I just want to separate a group of uri's that should have authorization before they can allow access. Jonathon McKitrick -- My other computer is your Windows box. From jcm at FreeBSD-uk.eu.org Wed Dec 20 20:41:02 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Wed, 20 Dec 2006 20:41:02 +0000 Subject: [hunchentoot-devel] Debug messages Message-ID: <20061220204101.GA79171@dogma.freebsd-uk.eu.org> I've noticed that when an error occurs in my code, hunchentoot displays an 'internal server error' page. Obviously this is good for a production environment, but during development, how can I see any debug output produced from the lisp system, perhaps in slime? That would be easier than checking log files. Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Wed Dec 20 21:41:28 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 20 Dec 2006 22:41:28 +0100 Subject: [hunchentoot-devel] Debug messages In-Reply-To: <20061220204101.GA79171@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Wed, 20 Dec 2006 20:41:02 +0000") References: <20061220204101.GA79171@dogma.freebsd-uk.eu.org> Message-ID: On Wed, 20 Dec 2006 20:41:02 +0000, Jonathon McKitrick wrote: > I've noticed that when an error occurs in my code, hunchentoot > displays an 'internal server error' page. Obviously this is good > for a production environment, but during development, how can I see > any debug output produced from the lisp system, perhaps in slime? > That would be easier than checking log files. http://weitz.de/hunchentoot/#log Read the whole section. At least... From gackle at shaw.ca Fri Dec 22 20:58:33 2006 From: gackle at shaw.ca (Daniel Gackle) Date: Fri, 22 Dec 2006 13:58:33 -0700 Subject: [hunchentoot-devel] Periodic socket error In-Reply-To: Message-ID: <0JAP00KEM0RIHOL0@l-daemon> I'm using Hunchentoot with ACL 8.0 Express. When a browser is open and displaying one of my app's URLs, the following error pops up every few minutes. Any ideas why would this be happening? Dan "Connection reset by peer" (errno 10054) occured while reading buffer for #. [Condition of type EXCL:SOCKET-ERROR] Restarts: 0: [USE-VALUE] Specify a character to be used instead. 1: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #) 1: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 0)) 2: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 3: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 4: (SWANK::CALL-WITH-REDIRECTED-IO # #) 5: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION # #) 6: (SWANK::CALL-WITH-CONNECTION # #) 7: (SWANK:SWANK-DEBUGGER-HOOK # #) 8: (INVOKE-DEBUGGER #) 9: (SIGNAL #) 10: (ERROR EXCL:SOCKET-ERROR :IDENTIFIER :CONNECTION-RESET :STREAM # :CODE 10054 :ACTION "reading buffer for") 11: ((METHOD EXCL:STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM))) 12: (FLEXI-STREAMS::READ-BYTE* #) 13: (FLEXI-STREAMS::READ-CHAR-8-BIT # #(0 1 2 3 4 5 6 7 8 9 ...)) 14: ((FLET (METHOD EXCL:STREAM-READ-CHAR (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) FLEXI-STREAMS::GET-CHAR-CODE)) 15: ((METHOD EXCL:STREAM-READ-CHAR (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) #) 16: ((METHOD EXCL:STREAM-PEEK-CHAR (EXCL:FUNDAMENTAL-CHARACTER-INPUT-STREAM)) #) 17: (CHUNGA:READ-LINE* #) 18: (HUNCHENTOOT::GET-REQUEST-DATA) 19: (HUNCHENTOOT::PROCESS-CONNECTION # #) From edi at agharta.de Fri Dec 22 21:05:38 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 22 Dec 2006 22:05:38 +0100 Subject: [hunchentoot-devel] Periodic socket error In-Reply-To: <0JAP00KEM0RIHOL0@l-daemon> (Daniel Gackle's message of "Fri, 22 Dec 2006 13:58:33 -0700") References: <0JAP00KEM0RIHOL0@l-daemon> Message-ID: On Fri, 22 Dec 2006 13:58:33 -0700, Daniel Gackle wrote: > I'm using Hunchentoot with ACL 8.0 Express. When a browser is open > and displaying one of my app's URLs, the following error pops up > every few minutes. Any ideas why would this be happening? > > "Connection reset by peer" (errno 10054) occured while > reading buffer for > # #2#/2227 @ #x20fe4d1a>. > [Condition of type EXCL:SOCKET-ERROR] I /think/ this is related to this thread: http://common-lisp.net/pipermail/tbnl-devel/2006-December/000871.html You've set *CATCH-ERRORS-P* to NIL, right? Yeah, looks like I should change this behaviour... Cheers, Edi. From edi at agharta.de Fri Dec 22 21:19:55 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 22 Dec 2006 22:19:55 +0100 Subject: [hunchentoot-devel] Periodic socket error In-Reply-To: <0JAP00A091OSKVW0@l-daemon> (Daniel Gackle's message of "Fri, 22 Dec 2006 14:18:28 -0700") References: <0JAP00A091OSKVW0@l-daemon> Message-ID: [Please use the mailing list.] On Fri, 22 Dec 2006 14:18:28 -0700, Daniel Gackle wrote: > Just out of curiosity, is this the worker thread that originally > sent the response to the browser? i.e. it's waiting for more > response material and dies after a while when there isn't any? Yes, that's most likely the case. There's a HTTP/1.1 connection between the browser and the server that both sides try to keep alive. The server (in the worker thread) keeps on reading (waiting for the next request) and gets a timeout after some time if the user doesn't do anything. The next request will then start a new worker thread. From jcm at FreeBSD-uk.eu.org Sat Dec 23 00:06:06 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Sat, 23 Dec 2006 00:06:06 +0000 Subject: [hunchentoot-devel] Odd messages, then hang Message-ID: <20061223000605.GA94674@dogma.freebsd-uk.eu.org> I'm seeing these odd messages after merging some code that calls a lot of XMLHttpRequest. That shouldn't matter, but it seems to have appeared suddenly since then. After the message, the server becomes unresponsive. message type 0x54 arrived from server while idle message type 0x44 arrived from server while idle message type 0x43 arrived from server while idle message type 0x5a arrived from server while idle I can't find this in the hunchentoot source, so I'm not sure where to look now. I'm running SBCL 1.0 on Linux. Jonathon McKitrick -- My other computer is your Windows box. From xach at xach.com Sat Dec 23 00:10:28 2006 From: xach at xach.com (Zach Beane) Date: Fri, 22 Dec 2006 19:10:28 -0500 Subject: [hunchentoot-devel] Odd messages, then hang In-Reply-To: <20061223000605.GA94674@dogma.freebsd-uk.eu.org> References: <20061223000605.GA94674@dogma.freebsd-uk.eu.org> Message-ID: <20061223001028.GX15105@xach.com> On Sat, Dec 23, 2006 at 12:06:06AM +0000, Jonathon McKitrick wrote: > > I'm seeing these odd messages after merging some code that calls a lot of > XMLHttpRequest. That shouldn't matter, but it seems to have appeared > suddenly since then. After the message, the server becomes unresponsive. > > message type 0x54 arrived from server while idle > message type 0x44 arrived from server while idle > message type 0x43 arrived from server while idle > message type 0x5a arrived from server while idle > > I can't find this in the hunchentoot source, so I'm not sure where to look > now. Use Google. Are you accessing a single DB connection from multiple threads? Don't do that, or synchronize access properly. Zach From jcm at FreeBSD-uk.eu.org Sat Dec 23 01:27:05 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Sat, 23 Dec 2006 01:27:05 +0000 Subject: [hunchentoot-devel] Odd messages, then hang In-Reply-To: <20061223001028.GX15105@xach.com> References: <20061223000605.GA94674@dogma.freebsd-uk.eu.org> <20061223001028.GX15105@xach.com> Message-ID: <20061223012705.GA95150@dogma.freebsd-uk.eu.org> On Fri, Dec 22, 2006 at 07:10:28PM -0500, Zach Beane wrote: : On Sat, Dec 23, 2006 at 12:06:06AM +0000, Jonathon McKitrick wrote: : > : > I'm seeing these odd messages after merging some code that calls a lot of : > XMLHttpRequest. That shouldn't matter, but it seems to have appeared : > suddenly since then. After the message, the server becomes unresponsive. : > : > message type 0x54 arrived from server while idle : > message type 0x44 arrived from server while idle : > message type 0x43 arrived from server while idle : > message type 0x5a arrived from server while idle : > : > I can't find this in the hunchentoot source, so I'm not sure where to look : > now. : : Use Google. Sorry, I thought it was coming from some ffi code in hunchentoot. : Are you accessing a single DB connection from multiple threads? Don't : do that, or synchronize access properly. Yes, that was it. I'm porting from single-threaded araneida. Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Sat Dec 23 22:01:18 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 23 Dec 2006 23:01:18 +0100 Subject: [hunchentoot-devel] Problems with create-folder-dispatcher-and-handler In-Reply-To: =?utf-8?q?=28Rafa=C5=82_Strzali=C5=84ski's?= message of "Thu, 7 Dec 2006 19:02:55 +0100") References: Message-ID: [Please use the mailing list if you're interested in timely replies.] On Thu, 7 Dec 2006 19:02:55 +0100, "Rafa? Strzali?ski" wrote: > (defun cfdah-dont-work () > (setf *dispatch-table* > (list > (x-create-folder-dispatcher-and-handler > "/" > #p"/" "text/plain")))) > > (defun cfdah-ok () > (setf *dispatch-table* > (list > (x-create-folder-dispatcher-and-handler > "/etc/" > #p"/etc/" "text/plain")))) I /think/ this is a bug in SBCL. I'll send a bug report to them. Cheers, Edi. From jeffrey at cunningham.net Sun Dec 24 00:37:16 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Sat, 23 Dec 2006 16:37:16 -0800 Subject: [hunchentoot-devel] logo Message-ID: <20061224003716.GA13333@achilles.olympus.net> Does anyone know an artist who can come up with a small Hunchentoot logo we can put on the bottom of websites? I tried to come up with one, but it was embarrasing (I'm no artist). It would be cool. I'm just using the lisp lizard for now linked back to Edi's site. --Jeff From mlist at rogers.com Sun Dec 24 01:02:37 2006 From: mlist at rogers.com (Dimitre Liotev) Date: Sat, 23 Dec 2006 20:02:37 -0500 Subject: [hunchentoot-devel] logo References: <20061224003716.GA13333@achilles.olympus.net> Message-ID: Jeffrey Cunningham writes: > Does anyone know an artist who can come up with a small Hunchentoot > logo we can put on the bottom of websites? I tried to come up with > one, but it was embarrasing (I'm no artist). It would be cool. I'm > just using the lisp lizard for now linked back to Edi's site. > > --Jeff "HUNCHENTOOT (The Giant Spider) - the miserable, hyper-negroid (harmonica virtuoso) love-slave of DRAKMA" [1]. Well, a "giant spider" wouldn't make a very attractive logo would it? I would go for something like a spider web enfolding the Earth - implying world domination of course... -- Dimitre 1. http://members.cox.net/bill_lantz/pages/hunchentoot.html From edi at agharta.de Sun Dec 24 10:19:16 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 24 Dec 2006 11:19:16 +0100 Subject: [hunchentoot-devel] Problems with create-folder-dispatcher-and-handler In-Reply-To: (Edi Weitz's message of "Sat, 23 Dec 2006 23:01:18 +0100") References: Message-ID: On Sat, 23 Dec 2006 23:01:18 +0100, Edi Weitz wrote: > I /think/ this is a bug in SBCL. I'll send a bug report to them. This has been fixed already: http://sbcl.boinkor.net/gitweb?p=sbcl.git;a=commit;h=c6ca3162c8abd6ae9cce613f5df5778405806e60 From jeffrey at cunningham.net Tue Dec 26 06:40:46 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Mon, 25 Dec 2006 22:40:46 -0800 Subject: [hunchentoot-devel] How to distinguish between two servers running same dispatch functions Message-ID: <20061226064046.GA8051@achilles.olympus.net> If I'm running two servers, each on a different port, but each running the same handler code, is there a way for a handler to tell which server has called it? --Jeff From edi at agharta.de Tue Dec 26 09:32:52 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 26 Dec 2006 10:32:52 +0100 Subject: [hunchentoot-devel] How to distinguish between two servers running same dispatch functions In-Reply-To: <20061226064046.GA8051@achilles.olympus.net> (Jeffrey Cunningham's message of "Mon, 25 Dec 2006 22:40:46 -0800") References: <20061226064046.GA8051@achilles.olympus.net> Message-ID: On Mon, 25 Dec 2006 22:40:46 -0800, Jeffrey Cunningham wrote: > If I'm running two servers, each on a different port, but each > running the same handler code, is there a way for a handler to tell > which server has called it? http://weitz.de/hunchentoot/#*server* From jcm at FreeBSD-uk.eu.org Tue Dec 26 18:27:41 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Tue, 26 Dec 2006 18:27:41 +0000 Subject: [hunchentoot-devel] Idle thread messages Message-ID: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> I searched the docs for 'idle' and 'thread' and google didn't turn up anything pertinent... is there any reason to be concerned about the idle thread messages that appear from time to time from hunchentoot? During debugging, they can pop up rather frequently in SLIME, and otherwise they are just logged to the console. Does this have anything to do with *cleanup-interval*? Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Tue Dec 26 19:23:17 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 26 Dec 2006 20:23:17 +0100 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Tue, 26 Dec 2006 18:27:41 +0000") References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> Message-ID: On Tue, 26 Dec 2006 18:27:41 +0000, Jonathon McKitrick wrote: > I searched the docs for 'idle' and 'thread' and google didn't turn > up anything pertinent... is there any reason to be concerned about > the idle thread messages that appear from time to time from > hunchentoot? During debugging, they can pop up rather frequently in > SLIME, and otherwise they are just logged to the console. Does this > have anything to do with *cleanup-interval*? What are these "idle thread messages?" How do they look like? Which Lisp are you using? Have you read the messages sent to the mailing list this month? Are your problems related to the timeout problems mentioned there? Cheers, Edi. From uvl at htg1.de Tue Dec 26 19:38:35 2006 From: uvl at htg1.de (Uwe von Loh) Date: Tue, 26 Dec 2006 20:38:35 +0100 Subject: [hunchentoot-devel] logo In-Reply-To: <20061224003716.GA13333@achilles.olympus.net> References: <20061224003716.GA13333@achilles.olympus.net> Message-ID: <45917A3B.1060005@htg1.de> My logo attempts over Christmas: http://www.htg1.de/hunchentoot/hunchentoot.html It's small, it's hypernegroid and it works on different backgrounds. Use the SVG for own disimprovements. Uwe 8-) Jeffrey Cunningham wrote: > Does anyone know an artist who can come up with a small Hunchentoot > logo we can put on the bottom of websites? I tried to come up with > one, but it was embarrasing (I'm no artist). It would be cool. I'm > just using the lisp lizard for now linked back to Edi's site. > > --Jeff > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From edi at agharta.de Tue Dec 26 19:46:25 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 26 Dec 2006 20:46:25 +0100 Subject: [hunchentoot-devel] logo In-Reply-To: <45917A3B.1060005@htg1.de> (Uwe von Loh's message of "Tue, 26 Dec 2006 20:38:35 +0100") References: <20061224003716.GA13333@achilles.olympus.net> <45917A3B.1060005@htg1.de> Message-ID: On Tue, 26 Dec 2006 20:38:35 +0100, Uwe von Loh wrote: > My logo attempts over Christmas: > > http://www.htg1.de/hunchentoot/hunchentoot.html > > It's small, it's hypernegroid and it works on different backgrounds. > Use the SVG for own disimprovements. Nice... :) What's the license? If you add one, I'll link to it from the Hunchentoot website. Cheers, Edi. From vamlists at gmail.com Tue Dec 26 20:01:46 2006 From: vamlists at gmail.com (Vamsee Kanakala) Date: Wed, 27 Dec 2006 01:31:46 +0530 Subject: [hunchentoot-devel] logo In-Reply-To: <45917A3B.1060005@htg1.de> References: <20061224003716.GA13333@achilles.olympus.net> <45917A3B.1060005@htg1.de> Message-ID: <45917FAA.7080307@gmail.com> Uwe von Loh wrote: > My logo attempts over Christmas: > > http://www.htg1.de/hunchentoot/hunchentoot.html > > It's small, it's hypernegroid and it works on different backgrounds. > Use the SVG for own disimprovements. The SVG version looks nice :). It would be great if you could also add the name 'HUNCHENTOOT' under the image in a nice font (sorry, my graphics skills aren't great). Thanks, Vamsee. From jeffrey at cunningham.net Tue Dec 26 20:13:02 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Tue, 26 Dec 2006 12:13:02 -0800 Subject: [hunchentoot-devel] logo In-Reply-To: <45917FAA.7080307@gmail.com> References: <20061224003716.GA13333@achilles.olympus.net> <45917A3B.1060005@htg1.de> <45917FAA.7080307@gmail.com> Message-ID: <20061226201302.GA22311@achilles.olympus.net> On Wed Dec 27, 2006 at 01:31:46AM +0530, Vamsee Kanakala wrote: > Uwe von Loh wrote: > > My logo attempts over Christmas: > > > > http://www.htg1.de/hunchentoot/hunchentoot.html > > > > It's small, it's hypernegroid and it works on different backgrounds. > > Use the SVG for own disimprovements. > > The SVG version looks nice :). It would be great if you could also add > the name 'HUNCHENTOOT' under the image in a nice font (sorry, my > graphics skills aren't great). > > I was just playing with that. Try these: --Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot1t.gif Type: image/gif Size: 798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot2t.gif Type: image/gif Size: 327 bytes Desc: not available URL: From edi at agharta.de Wed Dec 27 10:43:19 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 27 Dec 2006 11:43:19 +0100 Subject: [hunchentoot-devel] New release 0.4.12 (Was: logo) In-Reply-To: <45917A3B.1060005@htg1.de> (Uwe von Loh's message of "Tue, 26 Dec 2006 20:38:35 +0100") References: <20061224003716.GA13333@achilles.olympus.net> <45917A3B.1060005@htg1.de> Message-ID: ChangeLog: Version 0.4.12 2006-12-27 Added Hunchentoot logo by Uwe von Loh Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi. From edi at agharta.de Wed Dec 27 12:13:28 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 27 Dec 2006 13:13:28 +0100 Subject: [hunchentoot-devel] How to distinguish between two servers running same dispatch functions In-Reply-To: <20061226165828.GA17335@achilles.olympus.net> (Jeffrey Cunningham's message of "Tue, 26 Dec 2006 08:58:28 -0800") References: <20061226064046.GA8051@achilles.olympus.net> <20061226165828.GA17335@achilles.olympus.net> Message-ID: [Please use the mailing list.] On Tue, 26 Dec 2006 08:58:28 -0800, Jeffrey Cunningham wrote: > I must be missing something. From the handler, isn't one server > object indistinguishable from another? Huh? If you call START-SERVER, a SERVER object is returned, and you should better keep it anyway as you'll need it for STOP-SERVER. You can use EQ to compare this object with the contents of *SERVER*, can't you? > It can't access, say, the SERVER-PORT to tell which server has > called it. http://weitz.de/hunchentoot/#server-local-port http://weitz.de/hunchentoot/#server-address From edi at agharta.de Wed Dec 27 12:50:04 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 27 Dec 2006 13:50:04 +0100 Subject: [hunchentoot-devel] hunchentoot file upload performance In-Reply-To: (Edi Weitz's message of "Thu, 16 Nov 2006 01:30:05 +0100") References: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com> Message-ID: On Thu, 16 Nov 2006 01:30:05 +0100, Edi Weitz wrote: > Actually, the more I think about it the more I'm sure that > FLEXI-STREAMS is the culprit. I also have an idea how to make it > faster, but I'm not sure if I'll find the time to do it in the next > days. You might want to try out the new release (0.9.0) of FLEXI-STREAMS to see if this makes things more acceptable for you. SBCL (and problably CMUCL) users please note this, though: http://thread.gmane.org/gmane.lisp.steel-bank.general/1400/ Cheers, Edi. From jcm at FreeBSD-uk.eu.org Wed Dec 27 14:56:48 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Wed, 27 Dec 2006 14:56:48 +0000 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> Message-ID: <20061227145648.GA39560@dogma.freebsd-uk.eu.org> On Tue, Dec 26, 2006 at 08:23:17PM +0100, Edi Weitz wrote: : What are these "idle thread messages?" How do they look like? Which : Lisp are you using? Have you read the messages sent to the mailing : list this month? Are your problems related to the timeout problems : mentioned there? My fault, the answer did happen to be earlier this month, but as an aside, how difficult would it be to set up a search of all mail archives? That would be easier than having to scan each month separately. Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Wed Dec 27 15:06:31 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 27 Dec 2006 16:06:31 +0100 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: <20061227145648.GA39560@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Wed, 27 Dec 2006 14:56:48 +0000") References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> Message-ID: On Wed, 27 Dec 2006 14:56:48 +0000, Jonathon McKitrick wrote: > My fault, the answer did happen to be earlier this month, but as an > aside, how difficult would it be to set up a search of all mail > archives? That would be easier than having to scan each month > separately. That would be a question for the common-lisp.net maintainers. From gwking at metabang.com Wed Dec 27 15:14:35 2006 From: gwking at metabang.com (Gary King) Date: Wed, 27 Dec 2006 10:14:35 -0500 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> Message-ID: <5D42DFC4-7081-41D0-B6D1-AD5487672B13@metabang.com> FWIW, I find the default search setup to be frustrating too. What we _ought_ to do, of course, is use Montezuma to build our own full text search... but who has the time! sigh. On Dec 27, 2006, at 10:06 AM, Edi Weitz wrote: > On Wed, 27 Dec 2006 14:56:48 +0000, Jonathon McKitrick uk.eu.org> wrote: > >> My fault, the answer did happen to be earlier this month, but as an >> aside, how difficult would it be to set up a search of all mail >> archives? That would be easier than having to scan each month >> separately. > > That would be a question for the common-lisp.net maintainers. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From jcm at FreeBSD-uk.eu.org Wed Dec 27 15:17:33 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Wed, 27 Dec 2006 15:17:33 +0000 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> Message-ID: <20061227151733.GA39669@dogma.freebsd-uk.eu.org> On Wed, Dec 27, 2006 at 04:06:31PM +0100, Edi Weitz wrote: : On Wed, 27 Dec 2006 14:56:48 +0000, Jonathon McKitrick wrote: : : > My fault, the answer did happen to be earlier this month, but as an : > aside, how difficult would it be to set up a search of all mail : > archives? That would be easier than having to scan each month : > separately. : : That would be a question for the common-lisp.net maintainers. In penance for missing a few answers I should have found, I'd be willing to start on a FAQ, if you think it would serve any purpose. Jonathon McKitrick -- My other computer is your Windows box. From edi at agharta.de Wed Dec 27 15:42:51 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 27 Dec 2006 16:42:51 +0100 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: <20061227151733.GA39669@dogma.freebsd-uk.eu.org> (Jonathon McKitrick's message of "Wed, 27 Dec 2006 15:17:33 +0000") References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> <20061227151733.GA39669@dogma.freebsd-uk.eu.org> Message-ID: On Wed, 27 Dec 2006 15:17:33 +0000, Jonathon McKitrick wrote: > In penance for missing a few answers I should have found, I'd be > willing to start on a FAQ, if you think it would serve any purpose. For Hunchentoot? Please go ahead. Once you've come up with something, we can think about where to put it and how to maintain it. From jcm at FreeBSD-uk.eu.org Wed Dec 27 15:48:52 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Wed, 27 Dec 2006 15:48:52 +0000 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> <20061227151733.GA39669@dogma.freebsd-uk.eu.org> Message-ID: <20061227154852.GA39793@dogma.freebsd-uk.eu.org> On Wed, Dec 27, 2006 at 04:42:51PM +0100, Edi Weitz wrote: : On Wed, 27 Dec 2006 15:17:33 +0000, Jonathon McKitrick wrote: : : > In penance for missing a few answers I should have found, I'd be : > willing to start on a FAQ, if you think it would serve any purpose. : : For Hunchentoot? Please go ahead. Once you've come up with : something, we can think about where to put it and how to maintain it. I'd be happy to do something to 'give back.' I'm not very adept at generating markup, but I'll try to put something together. I'll start with my own questions. :-) Jonathon McKitrick -- My other computer is your Windows box. From jeffrey at cunningham.net Wed Dec 27 15:52:10 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Wed, 27 Dec 2006 07:52:10 -0800 Subject: [hunchentoot-devel] How to distinguish between two servers running same dispatch functions In-Reply-To: References: <20061226064046.GA8051@achilles.olympus.net> <20061226165828.GA17335@achilles.olympus.net> Message-ID: <20061227155210.GA10211@achilles.olympus.net> On Wed Dec 27, 2006 at 01:13:28PM +0100, Edi Weitz wrote: > [Please use the mailing list.] > > On Tue, 26 Dec 2006 08:58:28 -0800, Jeffrey Cunningham wrote: > > > I must be missing something. From the handler, isn't one server > > object indistinguishable from another? > > Huh? If you call START-SERVER, a SERVER object is returned, and you > should better keep it anyway as you'll need it for STOP-SERVER. You > can use EQ to compare this object with the contents of *SERVER*, can't > you? > > > It can't access, say, the SERVER-PORT to tell which server has > > called it. > > http://weitz.de/hunchentoot/#server-local-port > http://weitz.de/hunchentoot/#server-address > Sorry, Edi. I thought I did send my email to the list. I must have hit 'reply' (most lists I belong to have show the sender as the list). And I didn't see the SERVER-LOCAL-PORT function. Thanks. -Jeff From jeffrey at cunningham.net Wed Dec 27 16:15:24 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Wed, 27 Dec 2006 08:15:24 -0800 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: <20061227154852.GA39793@dogma.freebsd-uk.eu.org> References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> <20061227151733.GA39669@dogma.freebsd-uk.eu.org> <20061227154852.GA39793@dogma.freebsd-uk.eu.org> Message-ID: <20061227161524.GA10760@achilles.olympus.net> On Wed Dec 27, 2006 at 03:48:52PM +0000, Jonathon McKitrick wrote: > On Wed, Dec 27, 2006 at 04:42:51PM +0100, Edi Weitz wrote: > : On Wed, 27 Dec 2006 15:17:33 +0000, Jonathon McKitrick wrote: > : > : > In penance for missing a few answers I should have found, I'd be > : > willing to start on a FAQ, if you think it would serve any purpose. > : > : For Hunchentoot? Please go ahead. Once you've come up with > : something, we can think about where to put it and how to maintain it. > > I'd be happy to do something to 'give back.' I'm not very adept at generating > markup, but I'll try to put something together. I'll start with my own > questions. :-) And please include mine. I seem to have a knack for annoying Edi with dumb questions that seemed reasonable at the time. ;-) -Jeff From jcm at FreeBSD-uk.eu.org Wed Dec 27 17:41:48 2006 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Wed, 27 Dec 2006 17:41:48 +0000 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: <20061227161524.GA10760@achilles.olympus.net> References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> <20061227151733.GA39669@dogma.freebsd-uk.eu.org> <20061227154852.GA39793@dogma.freebsd-uk.eu.org> <20061227161524.GA10760@achilles.olympus.net> Message-ID: <20061227174148.GA40514@dogma.freebsd-uk.eu.org> On Wed, Dec 27, 2006 at 08:15:24AM -0800, Jeffrey Cunningham wrote: : And please include mine. I seem to have a knack for annoying Edi with : dumb questions that seemed reasonable at the time. I thought I had a monopoly on that. The wide release of hunchentoot across platforms will certainly try his patience. ;-) Jonathon McKitrick -- My other computer is your Windows box. From jeffrey at cunningham.net Thu Dec 28 20:57:27 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Thu, 28 Dec 2006 12:57:27 -0800 Subject: [hunchentoot-devel] Hunchentoot crashing behind mod_lisp with SSL Message-ID: <20061228205727.GA10101@achilles.olympus.net> I'm probably doing something dumb but I haven't been able to figure this out. My understanding of Apache is pretty limited. Both apache and my Hunchentoot servers work fine w/o SSL. My Hunchentoot server works fine *with* SSL standalone (not behind mod_lisp). But when I try put it behind mod_lisp and hit the domain with a browser (https://makewavs.com/) the Hunchentoot server goes into debug with the following message: The variable HUNCHENTOOT:*REPLY* is unbound. [Condition of type UNBOUND-VARIABLE] Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: ((SB-PCL::FAST-METHOD HUNCHENTOOT:LOG-MESSAGE (T #1="#<...>" . #1#)) # # :ERROR "Error while processing connection: ~A" #) Locals: HUNCHENTOOT::ARGS = (#) HUNCHENTOOT::FMT = "Error while processing connection: ~A" HUNCHENTOOT::LOG-LEVEL = :ERROR 1: ((LAMBDA (COND)) #) 2: ((LAMBDA (COND)) #) 3: (SIGNAL #) 4: (ERROR CL+SSL::SSL-ERROR-INITIALIZE) 5: (CL+SSL:MAKE-SSL-SERVER-STREAM #) 6: (HUNCHENTOOT::PROCESS-CONNECTION # #) 7: ((LAMBDA NIL)) 8: ("foreign function: call_into_lisp") 9: ("foreign function: funcall0") 10: ("foreign function: new_thread_trampoline") 11: ("foreign function: #xB7FB8604") I have apache listening on port 443 and using mod_lisp to talk to a Hunchentoot server on port 4433. The relevant vhosts setup in apache is: ServerName makewavs.com ServerAlias makewavs.com *.makewavs.com ServerAdmin webmaster at makewavs.com DocumentRoot "/domains/makewavs.com/htdocs" CustomLog /domains/makewavs.com/logs/ssl_access_log combined ErrorLog /domains/makewavs.com/logs/ssl_error_log LogLevel debug SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /domains/makewavs.com/htdocs/CA/ca-cert.pem SSLCertificateKeyFile /domains/makewavs.com/htdocs/CA/private/ca-key.pem Options Indexes FollowSymLinks Order allow,deny Allow from all Options Indexes FollowSymLinks Order allow,deny Allow from all LispServer 127.0.0.1 4433 "makewavs-ssl" SetHandler lisp-handler SSLOptions +StdEnvVars LispServer 127.0.0.1 4433 "makewavs-ssl" SetHandler lisp-handler SSLOptions +StdEnvVars The log ends up saying: [Thu Dec 28 12:33:31 2006] [info] Initial (No.1) HTTPS request received for child 65 (server makewavs.com:443) [Thu Dec 28 12:34:31 2006] [error] (70007)The timeout specified has expired: error reading from Lisp I'm running apache-2.0.58-r2, hunchentoot-0.4.12/, SBCL 1.0 on a gentoo system, and I've read through the last 3 months of the devel-list without seeing anything relevant. Any help would be appreciated. Regards, --Jeff From jeffrey at cunningham.net Thu Dec 28 21:06:56 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Thu, 28 Dec 2006 13:06:56 -0800 Subject: [hunchentoot-devel] Hunchentoot crashing behind mod_lisp with SSL In-Reply-To: <20061228205727.GA10101@achilles.olympus.net> References: <20061228205727.GA10101@achilles.olympus.net> Message-ID: <20061228210656.GA10402@achilles.olympus.net> I swear, I'm cursed. I resisted emailing the list for two hours and thought I'd tried everything. Not two minutes after I hit the send button I it occurs to me, "...if apache is handling SSL, maybe I need to *not* run SSL in Hunchentoot as its already been decoded..." So, I try running a straight Hunchentoot server and it works perfectly. This being the case, is the converse also true? I mean, can I have apache run without SSL and run Hunchentoot with SSL? And if so, is there any security or other advantage to configuring one way rather than the other? Sorry for the dumb questions. --Jeff From edi at agharta.de Thu Dec 28 21:09:16 2006 From: edi at agharta.de (Edi Weitz) Date: Thu, 28 Dec 2006 22:09:16 +0100 Subject: [hunchentoot-devel] Hunchentoot crashing behind mod_lisp with SSL In-Reply-To: <20061228205727.GA10101@achilles.olympus.net> (Jeffrey Cunningham's message of "Thu, 28 Dec 2006 12:57:27 -0800") References: <20061228205727.GA10101@achilles.olympus.net> Message-ID: On Thu, 28 Dec 2006 12:57:27 -0800, Jeffrey Cunningham wrote: > I'm probably doing something dumb but I haven't been able to figure > this out. My understanding of Apache is pretty limited. > > Both apache and my Hunchentoot servers work fine w/o SSL. My > Hunchentoot server works fine *with* SSL standalone (not behind > mod_lisp). But when I try put it behind mod_lisp and hit the domain > with a browser (https://makewavs.com/) the Hunchentoot server goes > into debug with the following message: > > The variable HUNCHENTOOT:*REPLY* is unbound. > [Condition of type UNBOUND-VARIABLE] Of course, you have SSL disabled in Hunchentoot while it's behind Apache, don't you? From edi at agharta.de Thu Dec 28 21:11:52 2006 From: edi at agharta.de (Edi Weitz) Date: Thu, 28 Dec 2006 22:11:52 +0100 Subject: [hunchentoot-devel] Hunchentoot crashing behind mod_lisp with SSL In-Reply-To: <20061228210656.GA10402@achilles.olympus.net> (Jeffrey Cunningham's message of "Thu, 28 Dec 2006 13:06:56 -0800") References: <20061228205727.GA10101@achilles.olympus.net> <20061228210656.GA10402@achilles.olympus.net> Message-ID: On Thu, 28 Dec 2006 13:06:56 -0800, Jeffrey Cunningham wrote: > This being the case, is the converse also true? I mean, can I have > apache run without SSL and run Hunchentoot with SSL? No. > And if so, is there any security or other advantage to configuring > one way rather than the other? If you want everything to be secure, you should make sure that the connection between Apache and mod_lisp is not vulnerable to attacks. Preferably, they should be on the same machine on only communicate via localhost. From jeffrey at cunningham.net Thu Dec 28 21:18:46 2006 From: jeffrey at cunningham.net (Jeffrey Cunningham) Date: Thu, 28 Dec 2006 13:18:46 -0800 Subject: [hunchentoot-devel] Hunchentoot crashing behind mod_lisp with SSL In-Reply-To: References: <20061228205727.GA10101@achilles.olympus.net> <20061228210656.GA10402@achilles.olympus.net> Message-ID: <20061228211846.GA10644@achilles.olympus.net> On Thu Dec 28, 2006 at 10:11:52PM +0100, Edi Weitz wrote: > > If you want everything to be secure, you should make sure that the > connection between Apache and mod_lisp is not vulnerable to attacks. > Preferably, they should be on the same machine on only communicate via > localhost. That is the case. Thank you, very much. -Jeff From ocorrain at yahoo.com Fri Dec 29 14:11:51 2006 From: ocorrain at yahoo.com (=?utf-8?B?VGlhcm7DoW4gw5MgQ29ycsOhaW4=?=) Date: Fri, 29 Dec 2006 14:11:51 +0000 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: <5D42DFC4-7081-41D0-B6D1-AD5487672B13@metabang.com> (Gary King's message of "Wed\, 27 Dec 2006 10\:14\:35 -0500") References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> <5D42DFC4-7081-41D0-B6D1-AD5487672B13@metabang.com> Message-ID: >>>>> "GK" == Gary King writes: GK> FWIW, I find the default search setup to be frustrating GK> too. What we _ought_ to do, of course, is use Montezuma to GK> build our own full text search... but who has the time! GK> sigh. Here's a quick Google custom search for the hunchentoot/tbnl mailing list: http://google.com/coop/cse?cx=002927904911724867201%3A0l5rif_cxj0 I have the snippet of code for a search box, if anyone wants it. -- Tiarn?n From edi at agharta.de Fri Dec 29 14:17:59 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 29 Dec 2006 15:17:59 +0100 Subject: [hunchentoot-devel] Idle thread messages In-Reply-To: =?iso-8859-1?q?=28Tiarn=E1n_=D3_Corr=E1in's?= message of "Fri, 29 Dec 2006 14:11:51 +0000") References: <20061226182741.GA20541@dogma.freebsd-uk.eu.org> <20061227145648.GA39560@dogma.freebsd-uk.eu.org> <5D42DFC4-7081-41D0-B6D1-AD5487672B13@metabang.com> Message-ID: On Fri, 29 Dec 2006 14:11:51 +0000, ocorrain at yahoo.com (Tiarn?n ? Corr?in) wrote: > Here's a quick Google custom search for the hunchentoot/tbnl mailing > list: > > http://google.com/coop/cse?cx=002927904911724867201%3A0l5rif_cxj0 Nice, thanks. I've added a link to this site to the Hunchentoot page. Cheers, Edi.