Hi list,
I don't often see messages of thanks on open source software mailing lists, so, without wishing to sound obsequious, let me buck the trend by thanking Edi, and everone else, before and since, for their work on hunchentoot.
I've found that setting this at the top level of cl-user:
(setf tbnl:*hunchentoot-default-external-format* tbnl::+utf-8+)
has no effect, other than preventing an error when a handler produces non-ascii text, i.e., the non-ascii text is garbled when displayed in the browser, despite including the line:
(setf (tbnl:content-type*) "text/html; charset=utf-8")
in the handler.
The problem is solved by also including the line:
(setf (tbnl:reply-external-format tbnl:*REPLY*) tbnl::+utf-8+)
in the handler, so what then is the purpose if the special variable?
Am I missing something?
Regards
Seb
Stop press!
It's not a hunchentoot issue. It's a SLIME/SWANK issue.
I've set things up so that hunchentoot, then my acceptors, and then my handlers are all loaded from my lisp implementation's init file.
The problem occurs immediately after start-up (M-x slime), regardless of whether my handler explicitly sets the output format or not, but if I then manually evaluate the handler (M-x slime-eval-last-expression) and reload the page in my browser the problem goes away.
Sorry for the noise.
Seb
Hi,
On Thu, Oct 8, 2009 at 9:27 PM, Sebastian Tennant sebyte@smolny.plus.com wrote:
I don't often see messages of thanks on open source software mailing lists, so, without wishing to sound obsequious, let me buck the trend by thanking Edi, and everone else, before and since, for their work on hunchentoot.
Thanks... :)
I've found that setting this at the top level of cl-user:
(setf tbnl:*hunchentoot-default-external-format* tbnl::+utf-8+)
has no effect, other than preventing an error when a handler produces non-ascii text, i.e., the non-ascii text is garbled when displayed in the browser, despite including the line:
(setf (tbnl:content-type*) "text/html; charset=utf-8")
in the handler.
The problem is solved by also including the line:
(setf (tbnl:reply-external-format tbnl:*REPLY*) tbnl::+utf-8+)
in the handler, so what then is the purpose if the special variable?
As explained in the documentation, the special variable *HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* is used when computing the /request/ object. As you said, it doesn't have an effect on the reply.
The test suite which is delivered with Hunchentoot contains examples for UTF-8 output.
HTH, Edi.
Quoth Edi Weitz edi@agharta.de:
*HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* is used when computing the /request/ object. As you said, it doesn't have an effect on the reply.
Ah... I missed that. Thanks for the clarification.
The need for a default encoding when computing the request object suggests to me that there must be such things as badly formed requests, i.e., ones from which the character encoding can't be reliably determined.? If so, which clients are the worst offenders, just out of interest?
The test suite which is delivered with Hunchentoot contains examples for UTF-8 output.
Noted.
Unfortunately, I can't pin the problem I'm having down. In my last post (which began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience the same weird behaviour if I run ccl from a shell.
In short, immediately after load'ing my handler via my init file at startup, any non-ascii text in my handler is garbled in the browser. If I then copy and paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is displayed correctly. What on earth could be causing this?
I'm using my development box (CCL in OS X) at the moment. I'm going to go and test it on my production box (SBCL in Debian). I don't know what else to try.
Seb
On Fri, Oct 9, 2009 at 11:54 AM, Sebastian Tennant sebyte@smolny.plus.com wrote:
The need for a default encoding when computing the request object suggests to me that there must be such things as badly formed requests, i.e., ones from which the character encoding can't be reliably determined.? If so, which clients are the worst offenders, just out of interest?
I'm not aware of specific offenders. Clients /should/ indicate the character encoding in the headers they send, so this is mainly a safety measure.
If you want to experiment yourself, take a look at the "GET/POST parameter handling with ... character set" tests in the Hunchentoot distribution and look at the headers specific clients send.
Unfortunately, I can't pin the problem I'm having down. In my last post (which began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience the same weird behaviour if I run ccl from a shell.
In short, immediately after load'ing my handler via my init file at startup, any non-ascii text in my handler is garbled in the browser. If I then copy and paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is displayed correctly. What on earth could be causing this?
I'm using my development box (CCL in OS X) at the moment. I'm going to go and test it on my production box (SBCL in Debian). I don't know what else to try.
I think you should first try to do this from the command line without Emacs to see if the problem remains. This very much (lacking a detailed description) sounds like an Emacs problem to me.
Quoth Edi Weitz edi@agharta.de:
I'm not aware of specific offenders. Clients /should/ indicate the character encoding in the headers they send, so this is mainly a safety measure.
Understood.
If you want to experiment yourself, take a look at the "GET/POST parameter handling with ... character set" tests in the Hunchentoot distribution and look at the headers specific clients send.
Noted.
I think you should first try to do this from the command line without Emacs to see if the problem remains. This very much (lacking a detailed description) sounds like an Emacs problem to me.
That's what I thought at first... but when I realised that the problem only occurs at the load'ing stage, I realised that it has nothing to do with Emacs. Using Emacs/SLIME/SWANK to re-evaluate the code just happened to fix it, but it wasn't causing it.
Anyway, the problem doesn't occur on my production box (SBCL in Debian Lenny) so it's not a major issue... something (the gods only know what) to do with... something else!
Seb
On Fri, 09 Oct 2009 09:54:38 +0000 Sebastian Tennant sebyte@smolny.plus.com wrote:
Unfortunately, I can't pin the problem I'm having down. In my last post (which began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience the same weird behaviour if I run ccl from a shell.
In short, immediately after load'ing my handler via my init file at startup, any non-ascii text in my handler is garbled in the browser. If I then copy and paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is displayed correctly. What on earth could be causing this?
This sounds suspiciously like a problem we were having where the locale wasn't properly set, resulting in SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* having a value that wasn't :UTF8.
Quoth Daniel White daniel@whitehouse.id.au:
On Fri, 09 Oct 2009 09:54:38 +0000 Sebastian Tennant sebyte@smolny.plus.com wrote:
Unfortunately, I can't pin the problem I'm having down. In my last post (which began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience the same weird behaviour if I run ccl from a shell.
In short, immediately after load'ing my handler via my init file at startup, any non-ascii text in my handler is garbled in the browser. If I then copy and paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is displayed correctly. What on earth could be causing this?
This sounds suspiciously like a problem we were having where the locale wasn't properly set, resulting in SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* having a value that wasn't :UTF8.
Hmm, just checked the value of SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* and it is correctly set (by default, as I've done nothing to change it).
The problem only occurs on my CCL development box anyway. I wonder what the CCL equivalent of SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* is?
Seb
On Oct 8, 2009, at 3:27 PM, Sebastian Tennant wrote:
Hi list,
I don't often see messages of thanks on open source software mailing lists, so, without wishing to sound obsequious, let me buck the trend by thanking Edi, and everone else, before and since, for their work on hunchentoot.
+1. Great software, much appreciated.
Regards,
Patrick
-
Daniel White -
Edi Weitz -
Patrick May -
Sebastian Tennant