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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
