tbnl-devel November 2009

tbnl-devel@common-lisp.net

19 participants
17 discussions

[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

[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

[hunchentoot-devel] Scieneer Common Lisp
by Bob Krzaczek 09 Nov '09

09 Nov '09

Hi, I'm happy to say that I've managed to get most of Hunchentoot up and running on Scieneer Common Lisp (Solaris 10, SPARC, 64 bit) today, with fairly minimal tweaks to its dependencies' sources. Still, I've run into some problems. A handful of the hunchentoot-test pages are coming back with HTTP's Bad Request. So, although it's very promising, it isn't all quite there yet. Anyway, the main reason I'm writing to the list is to ask if anyone else is working on SCL, before I attack this in earnest tomorrow? I just didn't want to step on toes, or duplicate someone else's effort. Cheers, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz(a)cis.rit.edu, icbm 43.0848N 77.6789W

2 1

[hunchentoot-devel] No REPL after hunchentoot:start
by quasi 06 Nov '09

06 Nov '09

Hey, I do not get the Slime REPL back after I start the webserver (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) I am using the latest Slime from CVS. SBCL 1.0.29 x86-64 on MBP with snow leopard. It works with Allegro 8.1. Am I missing something trivial here? thanks for the help, regards quasi

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel November 2009