November 2009 - tbnl-devel@common-lisp.net

[hunchentoot-devel] maybe bug + patch
by Richard KLINDA 06 Jun '10

06 Jun '10

Hello, I may have found a bug. After stopping an acceptor with STOP, one can't start it again with START, because the START method doesn't reset the value of acceptor-shutdown-p to NIL, so the listener returns/quits instantly. See the attached trivial patch, that fixes the issue for me, but maybe I'm just missing something here. -- Richard

3 2

[hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under hunchentoot 1.0
by Matthew Curry 21 Feb '10

21 Feb '10

Edi, I took a look at it tonight anyway, and there where some obvious minor fixes I spotted right away, attached is a patch that gets (using cadaver) an initial connection, a put, and a get to work. Just functions that were renamed in the new hunchentoot. Delete doesn't work, complains about a handler-done tag being unknown (but thrown). Here's the message log entry: [2009-11-15 20:55:06 [ERROR]] attempt to THROW to a tag that does not exist: HANDLER-DONE I'm not too familiar with older versions of hunchentoot, does that ring a bell for you? I'll keep looking. -Matt

3 15

[hunchentoot-devel] Backtrace display
by Jonathon McKitrick 27 Dec '09

27 Dec '09

I recall some time ago, the break and backtrace capability of Hunchentoot was removed, perhaps to make it less platform dependent. But I still find myself often trying to find the origin of cryptic error messages, and adding FORMAT and BREAK statements to narrow down the problem area. What is a good way to drop in support for, say, SBCL, so that an error will break into the debugger with a backtrace, or even dump the backtrace to the log file? -- Jonathon McKitrick

7 9

[hunchentoot-devel] Specializing process-request
by frode＠netfonds.no 22 Dec '09

22 Dec '09

Hi all, The Hunchentoot documentation at http://weitz.de/hunchentoot/ mentions that an around-method on process-request "might be a good place to introduce around methods which bind special variables or do other interesting things." In my eyes there's a problem with this, because the standard process-request sets up crucial parts of the dynamic environment for request processing, and around methods can only modify the scope outside of that. In particluar, error and warning conditions are handled before the around method gets a chance to intervene. I would suggest adding a new generic function that does just the dispatching, i.e. something like this: (defmethod dispatch-request ((*request* t)) (funcall (acceptor-request-dispatcher *acceptor*) *request*)) ..and have the kernel of the standard process-request method just call dispatch-request in the obvious way. I think this is a more appropriate configuration point for the request processing protocol than the current process-request is. (I can/could of course specialize process-request for my acceptor class using an unqualified method, and thus set up the dynamic environment just how I want it. However I would then just have to copy the full body of the standard process-request to insert a line or two inside the body of the handler-bind. I believe it's the purpose of a processing protocol to avoid having to do such things.) -- Frode V. Fjeld Netfonds Bank ASA

3 6

[hunchentoot-devel] updated version
by John Thingstad 22 Dec '09

22 Dec '09

Where is the the current SVN version of Hunchentoot that you are working on located? It seems the huncentoot version at www.weitz.de hasn't been updated in ages.

7 9

[hunchentoot-devel] Check regarding SSL with hunchentoot
by Mackram Raydan 25 Nov '09

25 Nov '09

Hey Everyone, I wanted to check regarding the use of SSL with hunchentoot behind a nginx proxy. Specifically when it comes to encryption key length is there anything specific that we should take care of and is hunchentoot SSL ready for a production system. Thanks for any help you can provide. Mackram Raydan Company: www.imagimate.com Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo

2 1

[hunchentoot-devel] [PATCH] debugging-acceptor breaks REDIRECT (among other things)
by Travis Cross 25 Nov '09

25 Nov '09

Greetings, The invoke-process-request-with-error-handling method on the debugging-acceptor gets a bit overzealous with catching unwinds. Because we throw to 'handler-done in various places, there are many unwinds that are not errors. In particular, REDIRECT throws, as does anything that calls ABORT-REQUEST-HANDLER (e.g. authorization-required replies, http-forbidden, http-not-found, etc.). The cleanest solution is to save a continuation before dropping into the debugger, then check to see whether we have a continuation to call during unwind. Patch is attached. (Thanks for providing a partial replacement for the old *catch-errors-p*, by the way.) Cheers, -- Travis Cross diff --git a/acceptor.lisp b/acceptor.lisp index 88118d7..70a8dc2 100644 --- a/acceptor.lisp +++ b/acceptor.lisp @@ -493,22 +493,19 @@ errors if *LOG-LISP-ERRORS-P* is set and logs warnings for *request* continuation) "Mechanism for entering the debugger if an unhandled error occurs while handling a request." - (let* ((aborted t)) + (let (unwind-continuation) (unwind-protect - (let ((*debugger-hook* - (lambda (cond prev-hook) - (setf aborted cond) - (let ((*debugger-hook* prev-hook)) - (invoke-debugger cond))))) - (with-simple-restart (abort "Abort handling ~A ~A" - (request-method *request*) - (request-uri *request*)) - (multiple-value-prog1 - (funcall continuation) - ;; When execution continues, close the stream only if so - ;; desired: - (setq aborted nil)))) - (when aborted - (when *headers-sent* - (setq *close-hunchentoot-stream* t)) - (throw 'handler-done (values nil aborted)))))) \ No newline at end of file + (let ((*debugger-hook* + (lambda (cond prev-hook) + (setq unwind-continuation + (lambda () + (when *headers-sent* + (setq *close-hunchentoot-stream* t)) + (throw 'handler-done (values nil cond)))) + (let ((*debugger-hook* prev-hook)) + (invoke-debugger cond))))) + (with-simple-restart (abort "Abort handling ~A ~A" + (request-method *request*) + (request-uri *request*)) + (funcall continuation))) + (when unwind-continuation (funcall unwind-continuation)))))

1 0

[hunchentoot-devel] Recursive lock when logging
by Slawek Zak 23 Nov '09

23 Nov '09

Hi, On svn-latest Hunchentoot I get this error when running on Allegro CL: #1=#<MULTIPROCESSING:PROCESS Hunchentoot worker (client: 192.168.0.136:48688)(10) @ #x72086c32> seizing #<MULTIPROCESSING:PROCESS-LOCK global-message-log-lock locked by #1# @ #x71e1393a> recursively [Condition of type SIMPLE-ERROR] Following knobs have been turned: (setq *log-lisp-errors-p* t) (setq *log-lisp-warnings-p* t) (setq *message-log-pathname* "log/message.log") (setq *access-log-pathname* "log/access.log") Thanks, /S

3 4

[hunchentoot-devel] Debugging acceptor issue
by Slawek Zak 23 Nov '09

23 Nov '09

Hey, I just started playing with the all-new debugging-acceptor. I run it using: (start (make-instance 'debugging-acceptor :port 8080 :debug-connection-errors-p t)) After setting up global stream redirection in swank I get segmentation fault on ACL 8.1/Linux. First time ever got a lisp process segfault on me :) So - what gives? Any special sugar I ought to add to make it sing? /S

2 1

[hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger)
by Andreas Fuchs 19 Nov '09

19 Nov '09

On Sun, Nov 15, 2009 at 12:58, Edi Weitz <edi(a)agharta.de> wrote: > Yes, I agree. I was probably a bit too over-enthusiastic with the > third bit... :) > > Still, I only have a finite amount of time. The Hunchentoot-specific > error handling was thrown out with the 1.0.0 release and if we add > something similar back in, I want it to be a reasonable, working, > flexible, and well-documented solution. That takes time, and I'll do > it when I have that time, this being not a priority for me right now. I have spent the last day working on a patch (incl. documentation) to include an error-handling mechanism in Hunchentoot, similar to the solution Peter posted some way up the thread (which was indeed a quick hack by me). This patch introduces an error handling protocol for connections and request handling. It introduces a new class and two new generic functions (all three exported and documented): * defclass debugging-acceptor: An acceptor that doesn't catch errors, instead relies on the implementation's debugger hook to catch the error and report it synchronously. * defgeneric invoke-process-connection-with-error-handling: An error handling mechanism for connection processing: Behavior for the regular hunchentoot:acceptor is the current default behavior. debuggable-acceptors only give you the debugger if their debug-connection-errors-p slot is non-NIL (NIL is the default) * defgeneric invoke-process-request-with-error-handling: An error handling mechanism for request handling: As before, the default behavior is in place for all subclasses of hunchentoot:acceptor except for debugging-acceptor. There, it invokes the debugger for signals raised with CL:ERROR. I hope very much that you find this worth including in the hunchentoot distribution. Of course, feedback is welcome. (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

6 13