The easiest I can think of is to put some garbage inside start-output function (headers.lisp) and execute a request from any server running on hunchentoot. Let's say right after (when (stringp content) ;; if the content is a string, convert it to the proper external format (setf content (string-to-octets content :external-format (reply-external-format*)))) put something like (/ 1 0) or (crazy-function a b). I wonder if I can write a test case to isolate it more so you wouldn't have to use your server code. Thank you, Andrei On Thu, Jan 20, 2011 at 2:38 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

Andrei,

can you provide us with a simple test case that exposes the unwanted behavior?  That'd make it easier for us to diagnose and maybe fix.

Thanks, Hans

On Thu, Jan 20, 2011 at 8:08 PM, AVS <lispercat@gmail.com> wrote:

...

Hi

Recently I was trying to find out why the client received an empty response. The problem was inside function start-output. Function call to (string-to-octets content :external-format (reply-external-format*) was throwing an exception (it was a non-latin character for latin external-format) which I couldn't catch in debugger by setting (setf hunchentoot:*handle-http-errors-p* nil) (setf hunchentoot:*handle-http-errors-p* t) (setf *catch-errors-p* nil)

Actually inside start-output I can write any crazy code that would fail to compile or throw an exception, but for some reason this error never gets shown at any level. Maybe I am just missing something that I can specify, or maybe it only happens on my end (I am using hunchentoot 1.1.1 on Ubuntu) please let me know.

Thank you, Andrei

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

The issue is this: If any of the functions fail when called from start-output, you'll receive an empty response and the debugger will not catch which function caused the error. I described in the previous message that in my case (string-to-octets ..) failed. The failure may depend on your input. I just said that to reproduce that scenario (silent error without debugger being invoked) just put any failing function inside start-output and issue a page request from the browser. You'll receive an empty page and no debugger will be signaled. Maybe it's a normal scenario, but it's hard to find the failing function in this case. Thank you, Andrei On Thu, Jan 20, 2011 at 4:04 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

On Thu, Jan 20, 2011 at 8:48 PM, AVS <lispercat@gmail.com> wrote:

...

The easiest I can think of is to put some garbage inside start-output function (headers.lisp) and execute a request from any server running on hunchentoot. Let's say right after    (when (stringp content)      ;; if the content is a string, convert it to the proper external format      (setf content (string-to-octets content :external-format (reply-external-format*))))

put something like (/ 1 0) or (crazy-function a b). I wonder if I can write a test case to isolate it more so you wouldn't have to use your server code.

I'm not sure if I understand you well, but are you changing Hunchentoot itself and find it hard to debug, or are you writing an application that uses Hunchentoot and find _that_ hard to debug.  If the former, I think you'll have to come up with a proposed patch to improve the behavior.  If the latter, I think I don't quite understand what the issue is.

-Hans

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

Very simple. I get a string from server A. I expect the string to be of latin characters. By (their) mistake there are a couple of unicode characters in the string. Now I want to use the string as part of my own server request handler which I do via: (defun handle-page-request () (no-cache) *string-with-unicode*) This request will produce an empty page. The developer says: "Why?! No debugger was triggered, it went completely silent!". The reason for that was when start-output called (string-to-octets content :external-format (reply-external-format*)), the default hunchentoot external-format is latin-1. Since there are unicode characters in content variable, string-to-octets will throw an exception which will not show anywhere. Go figure it was a problem in your content string and that string-to-octets blew up on it! I understand that in most cases the developer writes some kind cl-who code in the handler, or uses some content known to them. But there are cases when you are dealing with 3-d party content which you use to form your own. To fix their problem I now create a handler like: (defun handle-page-request () (no-cache) (setf (hunchentoot:reply-external-format*) (flex:make-external-format :utf-8 :eol-style :lf)) (setf (hunchentoot:content-type*) "text/html; charset=utf-8") *string-with-unicode*) Now, the problem I was talking about was that these types of errors are hard to find. If any exception thrown from within start-output triggered the debugger I'd find the root cause of the problem in no time. Thank you, Andrei On Thu, Jan 20, 2011 at 4:27 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat@gmail.com> wrote:

...

The issue is this: If any of the functions fail when called from start-output, you'll receive an empty response and the debugger will not catch which function caused the error. I described in the previous message that in my case (string-to-octets ..) failed. The failure may depend on your input. I just said that to reproduce that scenario (silent error without debugger being invoked) just put any failing function inside start-output and issue a page request from the browser. You'll receive an empty page and no debugger will be signaled. Maybe it's a normal scenario, but it's hard to find the failing function in this case.

I'm just trying to find out how pressing the problem is - Is it something that a user or an application developer may run into, or is it something that just happens when you poke around in the source code and break it in unexpected ways?  From quickly glancing at start-output, I see no calls back into user code, but you have run into it nevertheless.  How, why?

-Hans

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

The simplest I can think of is: (defun handle-page-request () (let ((str (make-array 0 :element-type 'character :fill-pointer 0 :adjustable t))) (dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK)) (vector-push-extend char str)) str)) Put this function in a dispatch table using something like (hunchentoot:create-regex-dispatcher "test.html" 'handle-page-request) When you type in "test.html" in the browser you'll see an empty page. If you fix the function like this: (defun handle-page-request () (setf (hunchentoot:reply-external-format*) (flex:make-external-format :utf-8 :eol-style :lf)) (setf (hunchentoot:content-type*) "text/html; charset=utf-8") (let ((str (make-array 0 :element-type 'character :fill-pointer 0 :adjustable t))) (dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK)) (vector-push-extend char str)) str)) You'll see ”test” in the browser. Andrew On Thu, Jan 20, 2011 at 4:58 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

Andrei,

thank you for your error description.  I now understand what the problem is and I agree that this is a bug that deserves fixing.  If you don't have a proposal how it can be fixed, it would be immensely helpful if you could provide me with a .lisp file that exposes the problem (maybe using drakma to send a request that makes the handler fail in the manner that you describe), as that would make it easier to start working on the solution.

Thanks, Hans

On Thu, Jan 20, 2011 at 10:45 PM, AVS <lispercat@gmail.com> wrote:

...

Very simple. I get a string from server A. I expect the string to be of latin characters. By (their) mistake there are a couple of unicode characters in the string. Now I want to use the string as part of my own server request handler which I do via: (defun handle-page-request ()    (no-cache)    *string-with-unicode*)

This request will produce an empty page. The developer says: "Why?! No debugger was triggered, it went completely silent!". The reason for that was when start-output called (string-to-octets content :external-format (reply-external-format*)), the default hunchentoot external-format is latin-1. Since there are unicode characters in content variable, string-to-octets will throw an exception which will not show anywhere. Go figure it was a problem in your content string and that string-to-octets blew up on it! I understand that in most cases the developer writes some kind cl-who code in the handler, or uses some content known to them. But there are cases when you are dealing with 3-d party content which you use to form your own.

To fix their problem I now create a handler like: (defun handle-page-request ()    (no-cache)    (setf (hunchentoot:reply-external-format*) (flex:make-external-format :utf-8 :eol-style :lf))    (setf (hunchentoot:content-type*) "text/html; charset=utf-8")    *string-with-unicode*)

Now, the problem I was talking about was that these types of errors are hard to find. If any exception thrown from within start-output triggered the debugger I'd find the root cause of the problem in no time.

Thank you, Andrei

On Thu, Jan 20, 2011 at 4:27 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

...

On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat@gmail.com> wrote:

...

The issue is this: If any of the functions fail when called from start-output, you'll receive an empty response and the debugger will not catch which function caused the error. I described in the previous message that in my case (string-to-octets ..) failed. The failure may depend on your input. I just said that to reproduce that scenario (silent error without debugger being invoked) just put any failing function inside start-output and issue a page request from the browser. You'll receive an empty page and no debugger will be signaled. Maybe it's a normal scenario, but it's hard to find the failing function in this case.

I'm just trying to find out how pressing the problem is - Is it something that a user or an application developer may run into, or is it something that just happens when you poke around in the source code and break it in unexpected ways?  From quickly glancing at start-output, I see no calls back into user code, but you have run into it nevertheless.  How, why?

-Hans

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

I'll try to do this. On you end do you see "test" or nothing? Must by some sbcl 1.0.37 issue probably... Andrew On Thu, Jan 20, 2011 at 5:44 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

Andrew,

I have been trying to reproduce the problem using CCL 1.6, but it does not occur for me.  Can you please prepare a .lisp file that is self-contained and that I can load to reproduce the problem that you see?

Thanks, Hans

On Thu, Jan 20, 2011 at 11:20 PM, AVS <lispercat@gmail.com> wrote:

...

The simplest I can think of is: (defun handle-page-request ()  (let ((str (make-array 0 :element-type 'character :fill-pointer 0 :adjustable t)))    (dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK))      (vector-push-extend char str))    str))

Put this function in a dispatch table using something like (hunchentoot:create-regex-dispatcher "test.html" 'handle-page-request) When you type in "test.html" in the browser you'll see an empty page.

If you fix the function like this: (defun handle-page-request ()  (setf (hunchentoot:reply-external-format*) (flex:make-external-format :utf-8 :eol-style :lf))  (setf (hunchentoot:content-type*) "text/html; charset=utf-8")

 (let ((str (make-array 0 :element-type 'character :fill-pointer 0 :adjustable t)))    (dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK))      (vector-push-extend char str))    str))

You'll see ”test” in the browser.

Andrew

On Thu, Jan 20, 2011 at 4:58 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

...

Andrei,

thank you for your error description.  I now understand what the problem is and I agree that this is a bug that deserves fixing.  If you don't have a proposal how it can be fixed, it would be immensely helpful if you could provide me with a .lisp file that exposes the problem (maybe using drakma to send a request that makes the handler fail in the manner that you describe), as that would make it easier to start working on the solution.

Thanks, Hans

On Thu, Jan 20, 2011 at 10:45 PM, AVS <lispercat@gmail.com> wrote:

...

Very simple. I get a string from server A. I expect the string to be of latin characters. By (their) mistake there are a couple of unicode characters in the string. Now I want to use the string as part of my own server request handler which I do via: (defun handle-page-request ()    (no-cache)    *string-with-unicode*)

This request will produce an empty page. The developer says: "Why?! No debugger was triggered, it went completely silent!". The reason for that was when start-output called (string-to-octets content :external-format (reply-external-format*)), the default hunchentoot external-format is latin-1. Since there are unicode characters in content variable, string-to-octets will throw an exception which will not show anywhere. Go figure it was a problem in your content string and that string-to-octets blew up on it! I understand that in most cases the developer writes some kind cl-who code in the handler, or uses some content known to them. But there are cases when you are dealing with 3-d party content which you use to form your own.

To fix their problem I now create a handler like: (defun handle-page-request ()    (no-cache)    (setf (hunchentoot:reply-external-format*) (flex:make-external-format :utf-8 :eol-style :lf))    (setf (hunchentoot:content-type*) "text/html; charset=utf-8")    *string-with-unicode*)

Now, the problem I was talking about was that these types of errors are hard to find. If any exception thrown from within start-output triggered the debugger I'd find the root cause of the problem in no time.

Thank you, Andrei

On Thu, Jan 20, 2011 at 4:27 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

...

On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat@gmail.com> wrote:

...

The issue is this: If any of the functions fail when called from start-output, you'll receive an empty response and the debugger will not catch which function caused the error. I described in the previous message that in my case (string-to-octets ..) failed. The failure may depend on your input. I just said that to reproduce that scenario (silent error without debugger being invoked) just put any failing function inside start-output and issue a page request from the browser. You'll receive an empty page and no debugger will be signaled. Maybe it's a normal scenario, but it's hard to find the failing function in this case.

I'm just trying to find out how pressing the problem is - Is it something that a user or an application developer may run into, or is it something that just happens when you poke around in the source code and break it in unexpected ways?  From quickly glancing at start-output, I see no calls back into user code, but you have run into it nevertheless.  How, why?

-Hans

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

Thank you for the suggestion, Hans. In the mean time could you try one thing? Put some bad code inside start-output that will cause an exception (for instance (list a b) without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil). If things are as they should be it'll trigger the debugger. In my case it doesn't which is the cause of the whole issue. If it triggers the debugger break for you, it means there is something related to sbcl I am using. Thank you, Andrei On Thu, Jan 20, 2011 at 6:11 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

On Thu, Jan 20, 2011 at 11:57 PM, AVS <lispercat@gmail.com> wrote:

...

I'll try to do this. On you end do you see "test" or nothing? Must by some sbcl 1.0.37 issue probably...

I just see the "test" as expected.  I think that what you see is some external format confusion.  This is not to say that there is no bug, but I can't currently reproduce the problem.  I would like to have a way to produce the problem with user code (i.e. without deliberately breaking Hunchentoot internally).

Thanks, Hans

P.S.: (coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK) 'string)

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

On Fri, 2011-01-21 at 06:40 +0100, Hans Hübner wrote:

On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat@gmail.com> wrote:

...

Thank you for the suggestion, Hans. In the mean time could you try one thing? Put some bad code inside start-output that will cause an exception (for instance (list a b) without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil). If things are as they should be it'll trigger the debugger. In my case it doesn't which is the cause of the whole issue. If it triggers the debugger break for you, it means there is something related to sbcl I am using.

The debugger is not triggered, so the bug is real. Having a way to reproduce it by user code would be helpful nevertheless.

-Hans

Like following? (defpackage :test (:nicknames :test ) (:use :cl :hunchentoot :cl-who) ) (in-package :test) ;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 )) (hunchentoot::define-easy-handler (eish :uri "/eish.html" :default-request-type :both) () (cl-who::with-html-output-to-string (*standard-output* nil :indent t) (cl-who::str "Hello World XXX"))) (defmacro with-debugging (&body body) ;; Using this as debugging tool because hunchentoot ;; swallows all errors here. `(handler-bind ((error #'invoke-debugger)) ,@body)) (defclass xxx () ((ccc)) ) (defmethod handle-request :before ((*acceptor* hunchentoot::acceptor) (*request* hunchentoot::request)) ; (with-debugging (slot-value (make-instance 'xxx) 'xxx) ;) ) Harag

Here is the standalone file to reproduce the unicode failure problem on my system (for the code below, put your path to quicklisp and save the code in a test.lisp file ): Load the file (for sbcl it's "sbcl --load test.lisp"), run lynx and type in "lynx 127.0.0.1:1234/test.html". It should give you an empty page. ;;test.lisp (load "/your-path/quicklisp/setup.lisp") (ql:quickload "hunchentoot") (defpackage :test (:use :cl :hunchentoot)) (in-package :test) (defparameter *server* (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1234))) (hunchentoot:define-easy-handler (test :uri "/test.html") (name) (coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK) 'string)) ;;file end Thank you, Andrei On Fri, Jan 21, 2011 at 5:05 AM, Hans Hübner <hans.huebner@gmail.com> wrote:

Harak, Andrei,

I had a look at the relevant positions in the Hunchentoot source and would be interested in solving the problem so that errors are reported, rather than swallowed, without requiring the user to set up special handlers.  My time is limited, though, so if you could help me by providing an executable test case that exposes the problem, it´d be greatly appreciated.

Thanks, Hans

On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx@gmail.com> wrote:

...

On Fri, 2011-01-21 at 06:40 +0100, Hans Hübner wrote:

On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat@gmail.com> wrote:

...

Thank you for the suggestion, Hans. In the mean time could you try one thing? Put some bad code inside start-output that will cause an exception (for instance (list a b) without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil). If things are as they should be it'll trigger the debugger. In my case it doesn't which is the cause of the whole issue. If it triggers the debugger break for you, it means there is something related to sbcl I am using.

The debugger is not triggered, so the bug is real.  Having a way to reproduce it by user code would be helpful nevertheless.

-Hans

Like following?

(defpackage :test   (:nicknames :test )   (:use :cl :hunchentoot :cl-who) )

(in-package :test)

;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))

(hunchentoot::define-easy-handler  (eish :uri "/eish.html" :default-request-type :both) ()    (cl-who::with-html-output-to-string (*standard-output* nil :indent t)      (cl-who::str "Hello World  XXX")))

(defmacro with-debugging (&body body)   ;; Using this as debugging tool because hunchentoot   ;; swallows all errors here.   `(handler-bind ((error #'invoke-debugger))      ,@body))

(defclass xxx ()   ((ccc)) )

(defmethod handle-request :before ((*acceptor* hunchentoot::acceptor) (*request* hunchentoot::request))

; (with-debugging    (slot-value (make-instance 'xxx) 'xxx) ;) )

Harag _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

I prepared a patch to improve Hunchentoot's error handling for errors that occur in START-OUTPUT. Please review http://bknr.net/trac/changeset/4637/trunk, update from svn+ssh://bknr.net/svn/ediware and try it out. Thanks! Hans On Fri, Jan 21, 2011 at 10:34 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

Hi Andrei,

thank you for sending the reproduction script.  Fixing the problem in a satisfactory fashion requires some refactoring that'll take me some time and require review.  I'll keep you posted.

-Hans

On Fri, Jan 21, 2011 at 5:15 PM, AVS <lispercat@gmail.com> wrote:

...

Here is the standalone file to reproduce the unicode failure problem on my system (for the code below, put your path to quicklisp and save the code in a test.lisp file ): Load the file (for sbcl it's "sbcl --load test.lisp"), run lynx and type in "lynx 127.0.0.1:1234/test.html". It should give you an empty page.

;;test.lisp (load "/your-path/quicklisp/setup.lisp") (ql:quickload "hunchentoot")

(defpackage :test  (:use :cl :hunchentoot))

(in-package :test)

(defparameter *server* (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1234))) (hunchentoot:define-easy-handler (test :uri "/test.html") (name)  (coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t #\RIGHT_DOUBLE_QUOTATION_MARK) 'string)) ;;file end

Thank you, Andrei

On Fri, Jan 21, 2011 at 5:05 AM, Hans Hübner <hans.huebner@gmail.com> wrote:

...

Harak, Andrei,

I had a look at the relevant positions in the Hunchentoot source and would be interested in solving the problem so that errors are reported, rather than swallowed, without requiring the user to set up special handlers.  My time is limited, though, so if you could help me by providing an executable test case that exposes the problem, it´d be greatly appreciated.

Thanks, Hans

On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx@gmail.com> wrote:

...

On Fri, 2011-01-21 at 06:40 +0100, Hans Hübner wrote:

On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat@gmail.com> wrote:

...

Thank you for the suggestion, Hans. In the mean time could you try one thing? Put some bad code inside start-output that will cause an exception (for instance (list a b) without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil). If things are as they should be it'll trigger the debugger. In my case it doesn't which is the cause of the whole issue. If it triggers the debugger break for you, it means there is something related to sbcl I am using.

The debugger is not triggered, so the bug is real.  Having a way to reproduce it by user code would be helpful nevertheless.

-Hans

Like following?

(defpackage :test   (:nicknames :test )   (:use :cl :hunchentoot :cl-who) )

(in-package :test)

;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))

(hunchentoot::define-easy-handler  (eish :uri "/eish.html" :default-request-type :both) ()    (cl-who::with-html-output-to-string (*standard-output* nil :indent t)      (cl-who::str "Hello World  XXX")))

(defmacro with-debugging (&body body)   ;; Using this as debugging tool because hunchentoot   ;; swallows all errors here.   `(handler-bind ((error #'invoke-debugger))      ,@body))

(defclass xxx ()   ((ccc)) )

(defmethod handle-request :before ((*acceptor* hunchentoot::acceptor) (*request* hunchentoot::request))

; (with-debugging    (slot-value (make-instance 'xxx) 'xxx) ;) )

Harag _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

On Sat, Jan 22, 2011 at 12:45 AM, AVS <lispercat@gmail.com> wrote:

Now it displays on the web page: Internal Server Error An error has occured

This is the right thing. You can set *SHOW-LISP-ERRORS-P* to display the error to the client, and *LOG-LISP-ERRORS-P* to log them to the log file.

If  (setf hunchentoot:*handle-http-errors-p* nil) it just says "An error has occured".

*HANDLE-HTTP-ERRORS-P* is not relevant here, I think. At least I did not intend to modify its behavior.

Still doesn't trigger the debugger when (setf *catch-errors-p* nil).

http://bknr.net/trac/changeset/4638/trunk fixes this. Please update and try again. -Hans