On Oct 30, 5:06 pm, "Dalius Dobravolskas"
<[EMAIL PROTECTED]> wrote:
> 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.
There are a lot of things that various WSGI implementations don't get
right. In mod_wsgi it tries to conform to the WSGI specification as
written. It also prohibits a few things in the interests of
encouraging people to write portable WSGI applications.
For example, mod_wsgi will complain about code writing to sys.stdout
directly or via 'print'. Similarly will complain about code which
tries to read form sys.stdin. These restrictions are put in place to
catch and highlight WSGI code which otherwise wouldn't be portable to
a WSGI implementation which uses sys.stdin/sys.stdout to communicate
with the server. The prime example of this is CGI and although CGI
isn't used as much as it was, still not an excuse to make WSGI
components not portable to it.
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
