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.