By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log, e.g. [ERROR]] Error while processing connection: #\U4F60 (code 20320) is not a LATIN-1 character. In 1.0 release, *break-on-signals* is used to enter the debugger In the old release and 1.1, when *catch-errors-p* is set as nil, the debugger will be entered. The related discussion thread can be found at: http://common-lisp.net/pipermail/tbnl-devel/2009-November/004928.html cheers Li 2010/1/23 Ron Garret <ron@flownet.com>
That was the problem. But why did it fail silently? I would have expected something along the line to complain about a non-encodable character.
rg
On Jan 22, 2010, at 7:32 PM, Li Gong wrote:
What's the value of *hunchentoot-default-external-format* ? By default, it is +latin-1+ To support UTF-8, change it as (setf *hunchentoot-default-external-format* (flex:make-external-format :utf8 :eol-style :lf))
My website still uses hunchentoot 0.15.7。It returns the non-ascii character page and always work fine.
2010/1/23 Ron Garret <ron@flownet.com>
Subject line says it all. If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently. No headers. No log messages. No errors. No nothing.
And as long as I'm at it, what does TBNL stand for?
Thanks, rg
_______________________________________________ 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