- tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[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

[hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server?
by Jeff Cunningham 16 Nov '09

16 Nov '09

I'm looking into setting up a Hunchentoot server on an OpenBSD system and right away noticed problems in the notes about building threads into SBCL (it sounds experimental). Lack of thread support would be a problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If so, were you able to use SBCL? If not, what did you use? Thanks. --Jeff

4 8

[hunchentoot-devel] PATCH: cl-webdav using the newer condition from the flexi-streams package
by Matthew Curry 16 Nov '09

16 Nov '09

flexi-streams package changed the name of the condition: flexi-stream-encoding-error to external-format-encoding-error Patch to cl-webdav attached. -Matt

2 2

[hunchentoot-devel] Invoke-debugger
by frode＠netfonds.no 15 Nov '09

15 Nov '09

There are numerous options for what to do when an error occurs while processing a hunchentoot request. But unless I'm missing something, there's no option to (effectively) call invoke-debugger? While developing and debugging, I find this to seeing a log message etc. It's rather easy to modify the standard process-request to call invoke-debugger, but wouldn't it make sense to have something like hunchentoot:*invoke-debugger-on-error-p* ? -- Frode V. Fjeld

5 13

[hunchentoot-devel] Customising PROCESS-REQUEST for continuous output
by Samium Gromoff 15 Nov '09

15 Nov '09

Good day folks, I would like to employ a handler which continuously writes to the socket stream, so that the appended output becomes immediately available to the page viewer. Basically, I'm building a buildbot for CL libraries, and the build process can be long, so I want the feedback to be available as immediately as possible. So, I look at PROCESS-REQUEST and I see that the handler returns before any output is written to the stream. My understanding is that I need to customize PROCESS-REQUEST, unless I want to take over header generation and can tolerate headers re-appended after my output. The easiest way would appear to be subclassing REQUEST and providing a modified method for PROCESS-REQUEST. But it appears that this is impossible to do without affecting all handlers using the same acceptor, as the class of the request employed is the property of the acceptor -- as is mandated by PROCESS-CONNECTION -- which, again, dispatches on the acceptor. So, there appears to be no way to customise hunchentoot in this regard, without changing its request processing workings. Or am I just missing something? regards, Samium Gromoff -- P.S. In case this sounds negative -- it wasn't so intended. Hunchentoot is a really great server! _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

2 2

[hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type
by frode＠netfonds.no 10 Nov '09

10 Nov '09

Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me. It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory. TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2" Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned. -- Frode V. Fjeld

4 13