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