On 8/14/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 14.08.2006, at 15:58, Gustaf Neumann wrote: > no rocket science (but work) This is precisely what I was afraid of: work. Not that I don't like, I just do not have time for that now. Moreover, the ns_http is a C-level implementation, which means some more work and much more instability as when you screw something at that level, everything goes down the drain. At the first glance, the nstest_http from the test-suite needs to be rewritten but as this is entirely written in tcl and affects only the test suite, this is less of a problem. More problematic is ns_http as this is a public call and is in the core server. This might affect everybody, so the stability is important. OTOH, this need not be done to get the test-suite pass. As I know Bernd is very fluent in Tcl and as he's now on the holiday (means he has a chance to relax and recover) I vote him to fix the test suite and rewrite the nstest_http :-)
Hello all.. Thanks Michael and Bernd for writing the new encoding tests! I actually picked them up on Friday and have been looking through the code this weekend. So with it all fresh in my mind, it was painful to catch up with the mailing list and see y'all struggle through it! I learnt a new phrase: Yak Shaving. You know when you start something, and them you realise it depends on something else so you need to do that first, and then you discover some other thing that *that* depends on so you start to work on that, and then another thing, and so on...? I've been Yak Shaving. The content-length bug is my fault. I busted it with the vectored IO changes, and it didn't come to light because we weren't testing character set conversion. Vlad suggested the chunked-encoding patch, and Bernd applied it (forgot the ChageLog, oops), but the tests didn't start failing until Michael added the encoding tests which changed the default output character set to iso-8859-1. I'd like to roll back that change. IIRC, the vectored IO changes are new since the last release so the existing tarball should be OK. It's also a one line patch so it's easy to apply if for some reason your dependent on HEAD. It does mess up a whole bunch of other tests and it's not the right way to fix this problem. I don't think nstest_http needs to be chunked encoding aware. There's no way a 5 byte response needs to be chunked! Besides, it's just a simple testing harness that needs to be somewhat not-conformant. I wrote it originally, rathern than use an existing client, because I needed to inject faults and see the server's response. Anyway. Encoding -- it's a bitch. As far as I can tell there's 3 situations you can find yourself in: * All your clients understand utf-8. You can serve them in whatever language you want using the one encoding. This should (be made to) work by default. * Your clients do not all understand utf-8, but you only support one other language. In this case, you can change the server default output encoding, and all should again, work by defaul (ignoring the current bugs). * Your clients don't understand utf-8, and you serve content in multiple languages which don't share a common character set. Sucks to be you. Rob Mayoff wrote the original encoding patches and wrote this helpful document to describe the situation: http://dqd.com/~mayoff/encoding-doc.html This was turn of the century and I'm wondering how much of this still applies today. How many clients do not support utf-8? I've been working on some patches to fix the various bugs so don't worry about it too much. But I'd appreciate feedback on how you actually use the encoding support. I'd explain more but I'm getting kicked off the wi-fi... Tomorrow.
