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
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.rgOn 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