[hunchentoot-devel] Returning a unicode string from a handler fails silently
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
Ron Garret <ron@flownet.com> writes:
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.
Works fine for me.
And as long as I'm at it, what does TBNL stand for?
To Be Named Later. Zach
On Fri, Jan 22, 2010 at 18:47, Ron Garret <ron@flownet.com> wrote:
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.
Does hunchtentoot-test fail for you as well? What version of Hunchentoot, compiler? Where did you get the dependencies from?
And as long as I'm at it, what does TBNL stand for?
T Be Named Later. Cheers, Hans
On Jan 22, 2010, at 7:23 PM, Hans Hübner wrote:
On Fri, Jan 22, 2010 at 18:47, Ron Garret <ron@flownet.com> wrote:
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.
Does hunchtentoot-test fail for you as well?
No, that works. Including the unicode tests. But that's because those get run through ENC. It's only if there's a non-HTML-entity-encoded unicode character in the returned string that it fails.
What version of Hunchentoot,
1.0.0
compiler?
CCL trunk.
Where did you get the dependencies from?
It's an Ediware snapshot from a few months ago. rg
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
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
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
On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
Nope: [ron@mickey:/tmp]$ pwd /tmp [ron@mickey:/tmp]$ ls hun* ls: hun*: No such file or directory I have generated other errors and log messages that showed up in the AltConsole (this is a CCL thing in case you don't know) but in this case nothing showed up there either. rg
On Sat, Jan 23, 2010 at 5:21 PM, Ron Garret <ron@flownet.com> wrote:
On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
Nope:
Most things in Hunchentoot are documented and so is logging: http://weitz.de/hunchentoot/#logging Logging to /tmp/hunchentoot.log was the default behaviour for pre-1.0 versions (on Unix-y systems), but it isn't anymore. Edi.
On Jan 23, 2010, at 8:38 AM, Edi Weitz wrote:
On Sat, Jan 23, 2010 at 5:21 PM, Ron Garret <ron@flownet.com> wrote:
On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
Nope:
Most things in Hunchentoot are documented and so is logging:
http://weitz.de/hunchentoot/#logging
Logging to /tmp/hunchentoot.log was the default behaviour for pre-1.0 versions (on Unix-y systems), but it isn't anymore.
Yes, I RTFM. I have *show-lisp-errors-p* set to T. Errors in other parts of the code show up just as I would expect. Log messages show up in the AltConsole. I've been happily debugging all manner of issues all day long. But this particular problem produces no debugging output that I can find. rg
On Jan 23, 2010, at 8:49 AM, Ron Garret wrote:
On Jan 23, 2010, at 8:38 AM, Edi Weitz wrote:
On Sat, Jan 23, 2010 at 5:21 PM, Ron Garret <ron@flownet.com> wrote:
On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
Nope:
Most things in Hunchentoot are documented and so is logging:
http://weitz.de/hunchentoot/#logging
Logging to /tmp/hunchentoot.log was the default behaviour for pre-1.0 versions (on Unix-y systems), but it isn't anymore.
Yes, I RTFM. I have *show-lisp-errors-p* set to T. Errors in other parts of the code show up just as I would expect. Log messages show up in the AltConsole. I've been happily debugging all manner of issues all day long. But this particular problem produces no debugging output that I can find.
OK, I figured it out. What I was seeing on the AltConsole was not logging output, it was the output of print statements in my code. I set *MESSAGE-LOG-PATHNAME* and all is now well. rg
participants (5)
-
Edi Weitz -
Hans Hübner -
Li Gong -
Ron Garret -
Zach Beane