5 messages in com.googlegroups.pylons-discussRe: Authkit (openid) + mod_wsgi| From | Sent On | Attachments |
|---|---|---|
| Dalius Dobravolskas | 29 Oct 2007 04:43 | |
| Dalius Dobravolskas | 29 Oct 2007 06:09 | |
| Graham Dumpleton | 29 Oct 2007 14:48 | |
| Dalius Dobravolskas | 29 Oct 2007 23:06 | |
| Graham Dumpleton | 30 Oct 2007 03:36 |
| Subject: | Re: Authkit (openid) + mod_wsgi![]() |
|---|---|
| From: | Dalius Dobravolskas (dali...@public.gmane.org) |
| Date: | 10/29/2007 11:06:29 PM |
| List: | com.googlegroups.pylons-discuss |
Hello, Graham,
The WSGI 1.0 standard requires that any headers (name or value) returned for a response are a string object, they cannot be unicode objects. Thus, make sure you are producing string objects and not unicode objects.
That's interesting when problem is in front of your eyes and you don't see it. The problem was in AuthKit. It uses start_response in following manner:
start_response( '200 OK',. [ ('Content-type', 'text/html'+self.charset), ('Content-length', len(response)) ] )
I guess that's enough usual form but len(response) is not string (nor 8-bit neither unicode). The fix is easy - str(len(response)).
What I actually don't like about following situation is that different WSGI implementations act different. That shouldn't be the case. This situation is even extreme case of that - you just get some error you don't imagine what it means and it is not even in your code (I personally don't make big problem here because I learned a lot valuable information). The easiest place to catch this error is in development phase but Paste(?) WSGI doesn't treat this situation as error while mod_wsgi does. Personally I think mod_wsgi is correct way to do things (at least that fits PEP 333) and other WSGI implementations should throw exception on non-string data.
-- Dalius http://blog.sandbox.lt




